Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
shayraber
Creator
Creator

load from select return different results

hi,

I'm working on a script which I didn't wrote.

the script part that saves data tend, lately, to return only few records from time to time (original source does not change)

the script is written in a way I'm not used to and i don't know if it might be the reason.

this is the script:


SQL SELECT * FROM system.dbo.MITX_USER_PROJ;
STORE MITX_USER_PROJ into $(Path_Full_QVD)\MITX_USER_PROJ (qvd);  DROP Table MITX_USER_PROJ;

instead of writing it:

MITX_USER_PROJ:
SQL SELECT * FROM system.dbo.MITX_USER_PROJ;
STORE * From MITX_USER_PROJ into $(Path_Full_QVD)\MITX_USER_PROJ.qvd (qvd);  DROP Table MITX_USER_PROJ;

(sometimes, instead of ~300Kb the result returns as a ~70Kb file)

can someone please assist?

happened to someone?

does the script change will help (not familiar with that file type)?

1 Solution

Accepted Solutions
marcus_sommer

I didn't meant something with the user or their privileges. I meant that if anyone is accessing the database the database could lock those records to avoid conflictings between multiple accesses at the same time - in general this is the default-beaviour from most of the database-types (and which could be sometimes to some degree customized).

- Marcus

View solution in original post

9 Replies
sunny_talwar

I think the more information in the script is always better. I would put the new script that your proposed

MITX_USER_PROJ:
SQL SELECT * FROM system.dbo.MITX_USER_PROJ;
STORE * From MITX_USER_PROJ into $(Path_Full_QVD)\MITX_USER_PROJ.qvd (qvd);  DROP Table
MITX_USER_PROJ;

marcus_sommer

I think that the syntax-adjustments won't be effect the number of records respectively the resulting file-size and I believe the reason for this behaviour is that the database returned a different number of records - maybe because there are some records blocked from other read- or write-handles in the database.

- Marcus

shayraber
Creator
Creator
Author

thanks, that's somthing i intend to do.

BUT

any idea why the result changes?

the script was scheduled to 2:30pm and the file stored was a file with size of 60Kb.

after sawing that, i've reloded the document manually at 3:00pm (half an hour later) and the result was (as it should have been from the begining) a file with size of 320Kb.

any thoughts?

shayraber
Creator
Creator
Author

thanks!

but

the syntax change was my idea since i heard (long time ago, when i learned QV) that the current syntax might cause problems.

second, the document was loaded twice in less than 30 minutes and the result came out different.

ONLY Source DB could be the issue?

(DBA says nothing is wrong with the user and its privileges)

sunny_talwar

Try this script:

SQL SELECT *

FROM system.dbo.MITX_USER_PROJ;
STORE MITX_USER_PROJ into $(Path_Full_QVD)\MITX_USER_PROJ_OLD (qvd);


DROP Table MITX_USER_PROJ;

MITX_USER_PROJ_NEW:
SQL SELECT *

FROM system.dbo.MITX_USER_PROJ;
STORE * From MITX_USER_PROJ_NEW into $(Path_Full_QVD)\MITX_USER_PROJ_NEW.qvd (qvd);


DROP Table MITX_USER_PROJ_NEW;


And check if you still see any difference between MITX_USER_PROJ_NEW.qvd and MITX_USER_PROJ_OLD.qvd

marcus_sommer

I didn't meant something with the user or their privileges. I meant that if anyone is accessing the database the database could lock those records to avoid conflictings between multiple accesses at the same time - in general this is the default-beaviour from most of the database-types (and which could be sometimes to some degree customized).

- Marcus

shayraber
Creator
Creator
Author

thanks

already did that

there was no different between the two options

what I've suspected is that the current script might be "unstable"

but no. the two ways resulted the same,

but on the other hand- something made the script to return a small file at first and larger file less than 30 minutes afterwards

sunny_talwar

Number of rows are the same? or did that change as well? Check the logfile to see if something is not right in one or the other?

shayraber
Creator
Creator
Author

that's probably the reason

was able to contact the guy who wrote the script

he said this is a customized table which sync with others and it happened before. it's a DB sync issue