
Default SQL and Delete mode
Started by Rob Donovan, Sep 15 2004 12:04 AM
5 replies to this topic
#1
Posted 15 September 2004 - 12:04 AM
Probably only related to Oracle tables.
If you have default SQL selecting records, and have a LU that has the file in Delete mode, and no logics anywhere on any of the file logic points, then all the records in the file are delete.
It does not follow the select you make in the default SQL.
Kernel Version: 5.5r323
Platform: Any
Rob D.
If you have default SQL selecting records, and have a LU that has the file in Delete mode, and no logics anywhere on any of the file logic points, then all the records in the file are delete.
It does not follow the select you make in the default SQL.
Kernel Version: 5.5r323
Platform: Any
Rob D.
#4
Posted 15 September 2004 - 10:50 AM
Hi,
Richard:
Nope, 'Confirmed' means that I have checked it myself.
Its more relavant for bugs posted form others.
I dont have the partial flag set.
Neil:
Not tried it in a screen, this test was in an update.
Rob.
Richard:
Nope, 'Confirmed' means that I have checked it myself.
Its more relavant for bugs posted form others.
I dont have the partial flag set.
Neil:
Not tried it in a screen, this test was in an update.
Rob.
#5
Posted 16 September 2004 - 09:34 AM
Ah, OK
I'd actually guess this could apply to any SQL database. From your description it would seem to be an issue with ProIV's "bulk delete" optimization - where there's a single file in delete mode with no logic I think ProIV tries to bypass the usual timing cycle and issue a single SQL DELETE for all the rows.
I guess maybe that can't work with explicit SQL because ProIV can't analyze your SELECT and morph it into the WHERE clause needed for the DELETE. This is kind of understandable but, if I'm guessing right, ProIV shouldn't be seeking to apply the "bulk delete" optimization where there is an explicit SELECT - that's the bug.
From your point of view you'd therefore probably get better performance by coding the DELETE statement directly and avoiding the whole problem.
Of course, this is all speculation..
I'd actually guess this could apply to any SQL database. From your description it would seem to be an issue with ProIV's "bulk delete" optimization - where there's a single file in delete mode with no logic I think ProIV tries to bypass the usual timing cycle and issue a single SQL DELETE for all the rows.
I guess maybe that can't work with explicit SQL because ProIV can't analyze your SELECT and morph it into the WHERE clause needed for the DELETE. This is kind of understandable but, if I'm guessing right, ProIV shouldn't be seeking to apply the "bulk delete" optimization where there is an explicit SELECT - that's the bug.
From your point of view you'd therefore probably get better performance by coding the DELETE statement directly and avoiding the whole problem.
Of course, this is all speculation..

Nothing's as simple as you think
#6
Posted 16 September 2004 - 10:40 AM
Spot on Richard,
Its easy to get around, once you know about it... but it could take you are while to figure it out.
Rob.
Its easy to get around, once you know about it... but it could take you are while to figure it out.
Rob.
Reply to this topic

0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users