Precision in the script

[datanibbler]

Hi,

I'm just struggling with a very strange phenomenon:

- I have a table in the Database - and the archived version of the same table (records are archived every 3 months or so)

- In a script, I was drawing the archived table (from beginning of last year) and appending the current table (implicitly)

- Up to yesterday, that worked fine

<=> Today I had the issue that a certain date (in June this year) was not found.

=> I checked and it seems that it was there in the archive_table written by the QlikView_loadscript - but not in the "master_table" I made out of the archive and the current ...

=> I don't know exactly what happened,  but it seems that the two tables were not actually concatenated (though they should have been because all fields must necessarily be equal), but rather the current one overwrote the archive.

=> That's why the record was in the archive at first, but in the total table it was not there ...

=> The conclusion I draw from this is simply this: In the script, always be as precise as you can be, specify tables even if it should not be necessary - if anything is implicit, you cannot be sure what might one day cause the whole thing to behave differently ...

Strange it is ...

[Peter_Cammaert]

Call it a best practice for the reason you mentioned and for one other reason as well: being explicit in your scripts at all times helps you in documenting your code without writing too many comments. That may not be immediately useful for whoever created the script in the first place, but it certainly will be for whoever takes over in the end...

Best,

Peter

[datanibbler]

Hi Peter,

that's right - documentation is for others in the first place - though it can turn out useful for yourself, too, if after a while you have to adapt your own code in some way.

Unfortunately, documentation is an often-neglected issue because properly documenting any development can take about as long as developing it took in the first place ...

[Digvijay_Singh]

Having standard test cases/verification checklist can also help to quick check if no of records/fields are not matching in involved tables. Even a  small change if go through without basic verification can create big troubles sometimes!