Initialisation interfering with extraction?

[jensmunnichs]

Hi everyone,

We have very recently started using the QDF, and I have encountered an issue. In one of our extraction apps, there is one table that is for some reason seen as vL.temp_table. All the fields are qualified and start with 'vL.temp_table.', and the table gets stored as vL.temp_table.

Now the strange thing is that this happens to the second table extracted from the system. I can probably solve this problem by naming the table during the extraction statement, but I'm just wondering why this is happening? The vL.temp_table is dropped during initialisation, so I don't understand how it could interfere with the rest of the script at all? I am mostly curious because I don't want to run into similar issues in the future without noticing.

I don't think I can post the exact script but it goes as follows:

<Set system variables>

<Include InitLink.qvs>

<Connect to database>

Qualify *;

SELECT*
FROM <table>;
Repeat for about 15 tables

<Loop to store tables>

<Loop to drop tables>

Thanks for any help provided!

[Vegar]

I usally do something like this:

For each vTable in 'Table1', 'Table2', ... ,'Table15'
[$(vTable)]:
SELECT*
FROM DATABASE.dbo.$(vTable);
next

[jensmunnichs]

Hi Vegar,

Thank you for your reply. This does fix the problem, but I am still curious why it would 'randomly' replace the name of one of my tables with the name of a table that has already been dropped earlier in the script. I know it doesn't really matter in this case, I'd just like to know so I can hopefully avoid similar problems in the future.

Any ideas?

[bartsa]

Replying to an old thread, but hopefully someone dealing with the same issue finds the solution.

The problem for us was that the tables are not given a name during the load. This creates the vL.temp_table in some point of the reload while QDF is active.  So a solution for us was to give the table name in a variable for each table.

Hope this helps!