Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
in order to avoid field name conflicts I use a lot of 'store' sentences creating a lot of qvds.
At the end I have many useless qvds.
Is there a way to eliminate them at the end of the script?
Thanks
EXECUTE cmd.exe /c DEL C:\file.qvd
Probably you can create table in memory instead of qvd, in the same way you can refer to tables in memory and when you do not need them anymore use Drop table instruction.
Sure, using EXECUTE and operating system command DEL. This will mark the script as unsafe (EXECUTE could potentially do anything), although you can disable the warning in user preferences. If you are developing for a QV Publisher environment, I'd create a supporting task to wipe the qvds after reload.
Hi,
if I understood properly, using memory tables I have to deal with many equal field names at the same time this is why use 'store' + 'drop table' maybe is there a better way to avoid the conflict but I do not know it.
As for EXECUTE and DEL, could you please tell me an example to erase a file.qvd placed in c:\ for example?
thanks a lot
And on the next reload they will be created again overwriting the current ones. So what? Disk space is cheap these days. Why bother cleaning them up? Just store them in a work folder and leave them there unless you really need the disk space.
How about the QUALIFY statement? This will precede each fieldname with its tablename, avoiding having to deal with many equal field names at the same time..
Hi Luis,
What about renaming the fields that are clashing to something more descriptive ?
Other than this you could use the QUALIFY\UNQUALIFY statements that have already been mentioned.
Or split the creation of the qvds into more than one document.
Thanks
Mark
EXECUTE cmd.exe /c DEL C:\file.qvd
Hi Luis,
I would prefer Alessandro's recommendation. There are no field name conflicts until the script ends and QlikView begins building associations. Everything is in RAM, i.e. fast. I use this approach a lot.
Good Luck
I disagree - how about autoconcatination of tables with the same field names, Sergey? Or using a where exists(Fieldname) clause in a load.