-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.0.17/1.0.18 regression: COMMIT
and ROLLBACK
delete all cursor definitions -> Status -111
#119
Comments
gixsql/runtime/libgixsql/gixsql.cpp Lines 293 to 319 in b907882
commenting line 294 leads to "program runs again" (like it did with a previous version of GixSQL) - but I haven't checked the implications and possible issues of doing so. |
From what I can see, you are probably right. This part will be overhauled anyway when tackling the "autocommit" stuff (this is why |
What do you think about working with milestones on GitHub to schedule and group issues and give some "progress" people can see? [feel totally free to say "no thanks" :-) ] |
Yes, that would be nice :-) Starting in these days, and in the next few weeks, I'll be busier with my day-job and - in the end of September/first half of October - some vacation, but when I get back, I'd like to tackle this and give some more "structure" to the project. This will also encompass Gix-IDE: the new debugger is almost ready for launch, even if in a pre-release form, and this will help speed up the development of the IDE itself. |
While waiting for the "autocommit overhaul" in 1.0.19, this patch might fix this. I have developed a test case (included below) just in a single program (no p119.patch.txt Edit: due to a mistake the patchincludes the fix in PR #127, just skip the block if you already applied it locally |
Should this be solved in 1.0.19? I get a SIGSEGV on cursor close (on
likely happens because that cursor data is not valid anymore. |
friendly ping @mridoni |
Yes, this should be solved in v1.0.19, that part has been modified to accomodate for the new autocommit support. During the holidays I am going to perform some triage and close some stale issues, this is probably needed to keep a clear view of what's going on (i guess one can always re-open them 😄) |
Ok then we need a new issue for the SIGSEGV from above - as this was seen in 1.0.19
|
Opened #135 to track it, but this should disappear in v1.0.20 anyway (including dev versions) since all those allocations are now handled with smart pointers. |
The main question is: is that correct, but I'm quite sure it isn't.
The current code leads to:
PROG1 -> PROG2 (OPEN + READ CURSOR2 + CLOSE)
PROG1 -> PROG3 (OPEN + READ CURSOR3 + CLOSE)
PROG1 -> PROG4 (OPEN + READ CURSOR4 + CLOSE)
PROG1 COMMIT
PROG1 -> PROG2 (OPEN CURSOR2)
-> returns sqlcode -111, sqlstat "24518" sqlmessage "No such cursor"
each of PROG2-4 executes a cursor open which automatically declares the cursor internally because "GIXSQL-CI-F-PROGn-CSKEY01N = ' ' ) but the
COMMIT
executed viaGIXSQLExec
->_gixsqlExec
goes toCursorManager::clearConnectionCursors
which removes the definition of every known cursor viaCursorManager::remove
.I think what would be reasonable is to close the cursors, but not remove the internal definition... and I think that this issue should actually should postpone 1.0.18a :-(
The text was updated successfully, but these errors were encountered: