I am getting the thread issue with transactions also. I am using SQL Server 2008 Express. No changes to code but just upgraded to Servoy 5.2.3 and started getting the issue.
On further investigation I have found that for me it happens when I start a transaction and then create a new record, then try to save the record. If I start a transaction and edit an existing record I don’t get the error.
Also, it only happens on some tables in my solution. It seems to be tables that were added when my solution was using Servoy 4 have the problem. As my solution has been upgraded through Servoy versions to 5 and new tables added, these new tables work OK.
I exported my solution with data, created a blank database, re-pointed my db server to this blank db, imported my solution creating all the tables and data, and now it all works OK and I don’t get the error.
For us though this is not a fix, as we have many customers who need to be upgraded without recreating their whole database.
Regarding the transaction commit issue: we are using SQL Server 2008 and PostgreSQL and so far have not experienced this issue. However, in our case the database schema is created and maintained outside of Servoy.
Same with us :
the database schema is created and maintained outside of Servoy.
I have here 3 tracelogs of 3 different tables I use an in-memory transaction on. The code to save the transactions is the same method.
2 of the logs show the error, 1 however does work.
Also my schema is created and maintained outside of Servoy (not that I think this should matter) and I use dbidenties, not servoy sequences.
tracelogs.zip (10.9 KB)
Robert, Jeff,
This issue occurs when you insert a new record of a table that has db-managed or db-default columns.
And only when you save the new record(s) from within a transaction.
We are working on fixing this now.
Thanks,
Rob
will there be an intermediate release for this ??
I hope so, because we need the other fixes in 5.2.3 urgently !
Regards,
rgansevles:
This issue occurs when you insert a new record of a table that has db-managed or db-default columns.
And only when you save the new record(s) from within a transaction.
My save-record code does indeed use a db transaction. (see http://www.servoycamp.com/topics/tutori … tions.html)
Or are you talking about in-memory transactions ?
Robert,
It happens with transactions started with databaseManager.startTransaction() and only wit inserts for tables with columns that are db-managed or have db-default values.
Rob
Rob,
What do you mean by db-managed ?
Regards,
I assume it means database sequences via default value functions (like with PostgreSQL) or via triggers (like with Oracle).
The display type “TYPE_AHEAD” doesn’t work the same as on 5.1.0
Does any one else having any issue with this display type?
It uses to work on 5.1.0.
I am using on a related table view, where a field uses a value list base on a global variable. It doesn’t show on inserting the first record, but it shows on editing existing records.
jvalencia:
I am using on a related table view, where a field uses a value list base on a global variable. It doesn’t show on inserting the first record, but it shows on editing existing records.
do you have a small example that you can attach to a case?
where is for example that valuelist list based on? I guess that you mean that it is a global relation that it should show? (and the dataprovider is just a record/table value)
embedded js/css header contributions that are contributed through for example a tab switch is fixed for 5.2.4, it was a bug that crept in the wicket 1.4.14 release that was shipped with 5.2.3
jcompagner:
embedded js/css header contributions that are contributed through for example a tab switch is fixed for 5.2.4, it was a bug that crept in the wicket 1.4.14 release that was shipped with 5.2.3
This is great! Any information as to when we might expect the release of 5.2.4?
Just to let you know that the fix for the transaction related error is absolutely required for us to move forward with updates. Thanks.
M.S.
The tranasction issue only happens in combination with default table values defined at the database.
We are working on the 5.2.4 version, which is expected early next week.
Since this version we cannot sign plugins\quartz.jar using the signtester.jar
Unsigning: quartz.jar
Operation aborted due to : java.util.zip.ZipException: invalid entry compressed size (expected 7909 but got 8103 bytes)
C:\Program Files (x86)\Servoy\application_server\.\plugins\scheduler\quartz.jar did verify but will be overwritten
C:\Program Files (x86)\Servoy\application_server\.\plugins\scheduler\quartz.jar signed
It looks like it’s not a correct zip-file.
I’ve seen this error in 5.2.2 with some other jars also.
Nevertheless, these jars seemed to have got a new signature as I wasn’t prompted for any strange signature when running the solution in smart client.
We are using signtester.jar with option overwrite.
After signing the original quartz.jar-file and a quartz.sig file are in the <SERVOY_HOME>\application_server\plugins\scheduler\ directory.
The quartz.jar shipped with 5.2.3 is different than the file shipped with 5.2.2. The 5.2.2 file does nog give any problems.
Could it be that the shipped file it is corrupt (according to: java.util.zip it is) or is this a signtester.jar problem?
the problem that quartz.jar had in 5.2.2 is that it couldnt be repacked on the server (in the work dir of your server work/tmp catalina dir you did see a quartz.jar.gz nog a quartz.jar.gz.pack)
what we did is repack/resign it a again. Now it seems to be packed just fine. But it seems that now signtester bombs out on that one
Does on your install the scheduler work for example? (thats quartz)