Got a few failures reloading QV applications on QVS. Log files, in all cases, ended with this:
QVX_PIPE_ERROR:
Error: OLEDB read failed
General Script Error
Execution Failed
Execution finished.
None of the applications is using QVX, all load data from SQL database using OLEDB connect, and from Excel files. The error message is apparently misleading. The only common thing in all cases that there were two reloads running at the same time - one is triggered by scheduler, another by EDX.
Repeating reload at the time when nothing else is reloading - works fine.
Did you ever get any resolution on this? I've got a customer with the same QVX_PIPE_ERROR occuring randomly on a single application during server reloads.
@Michael: Qlikview is using QVX to transfer the data between the connector(32/64) process an the qlikview application.
@Rob: I had this bug in combination with the navision odbc driver, but QT support told me that is an error of the odbc driver, so they closed the case.
No, I didn't do anything about it. When I get notification about the reload failure, I just initiate reload again. Going to upgrade to QV 11.20 SR2 soon, will see if it changes anything.
Konrad,
Thanks for this info. I don't use ODBC connection.
Amongst the greats of the community....i wud like to present what i tried and it worked for me.
May be it helps you as well:
I noticed that if i'm fetching multiple tables in a single qvw, saving them to qvds and dropping the table,one by one,i get the error in the script exceution progress only when the 2nd table is fetched and not for the 1st table fetch.
So this is what i did:
"Before every new load of the table from the Database i just copied and pasted the ODBC connection string"
For eg.
ODBC connect to DSN(username,password)
tab1:
SQL select * from tablename1;
store....qvd;
drop table tab1;
/// I got the error here
ODBC connect to DSN(username,password)
tab2:
SQL select * from tablename2;
store....qvd;
drop table tab2;
........
In case the two tables are on different servers/DSNs i used 'Disconnect' explicitly before the connecting to new DSN.
For eg.
ODBC connect to DSN1(username,password)
tab1:
SQL select * from tablename1;
store....qvd;
drop table tab1;
Disconnect;
ODBC connect to DSN2(username,password)
tab2:
SQL select * from tablename2;
store....qvd;
drop table tab2;
It worked for me. I would be pleased to know the results for you.
I've tried adding a CONNECT before each SQL SELECT and it improved the problem for some time, but not completely. It appears to be a timing problem and anything that changes the timing -- and maybe slows things down -- seems to make the problem move around as well.
1) "When I increased "number of tries", the problem's non-existent."--Where can i increase the no. of tries, QMC ?
2) "I got an impression that it happens when two reloads are reading data from the same QVD at the same time."--
I'm sure it is not the reason, i reload 3 qvws parallely reading data from same qvd exactly at the same time daily(running on the success of the common qvd maker set in QMC). 2qvws again reading from same qvds at the same time daily. They've never failed.
One which has failed due to this error is their qvd makers which only read from the Database & write qvd to disk ( don't read qvds).
So, (1) seems more reasonable.
the interesting thing here is the error code: why does it contain 'QVX', something do with the connection to the datasource ?
