Dropping SQL REST Table not working (?)

[therealdees]

Hi,

I've just set a script to request data from an API and it works with a loop, changing the id value dynamically.

The first iteration works as expected, but even tho I drop the table ''message" [the table name] that receives the response, it seems to keep the table in memory and therefore in the next iteration it either concatenates the tables or renames the table to something like message-2 (if I use NoConcatenate).

What's going on? How can I overcome this?

[rubenmarin]

Hi, I haven't heard of this before, maybe some control sentence is skipping the drop table or recreating a new one. I will try to run the script in debug mode to confirm that it executes the drop table sentence, you can try to add a resident load from that table after the drop to confirm if the table still exists after the drop.

If it's deleted, continue the debug to detect when it's created again.

[therealdees]

Hi, Ruben!

Sorry for the delay and thanks for the reply.

I just got back to this subject and the problem persists. It is very strange indeed... I was actually doing what you suggested, debugging the script and trying to resident load the 'message' table and the table wasn't recognized, only if I added an index number: Resident message-1, etc...

Anyways, I managed to workaround the issue by concatenating the rows to an empty table I loaded prior the iteration. For some reason it works that way, maybe it's something related to the fact that the 'message' table is a default table that is loaded by the REST connector, maybe it's persistent in memory for whatever reason.

I won't go further in this subject as I got it to work, but thank you for your help and time!!