[
https://issues.apache.org/jira/browse/EMPIREDB-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16744782#comment-16744782
]
jan edited comment on EMPIREDB-283 at 1/17/19 8:27 AM:
-------------------------------------------------------
[~doebele]:
I just had a look at the dumps and did a test-restore.
My production system dump milliseconds in timestamps but my dev system does not:
Production:
-- written by empire-db
=> select update_timestamp from ... where id = 1;
update_timestamp
-------------------------
2018-10-11 14:49:54.129
(1 row)
-- dump
$ pg_dump -h localhost -U ... ... -f test.dump
This dump has in fact 2018-10-11 14:49:54.129 as update timestamp. No problem
here.
Test system:
-- import dump
$ psql -h localhost -U ... -f test.dump
=> select update_timestamp from ... where id = 1;
update_timestamp
-------------------------
2018-10-11 14:49:54.129
(1 Zeile)
imported dump - milliseconds still there.
Trying to update with empire-db:
INFO [2019/01/17 09:20]: Executing: UPDATE ...
SET FOO='BAR', UPDATE_TIMESTAMP='2019-01-17 09:20:16'
WHERE ID=1 AND UPDATE_TIMESTAMP='2018-10-11 14:49:54' at
org.apache.empire.db.DBDatabase.executeSQL(DBDatabase.java:1417)
INFO [2019/01/17 09:20]: executeSQL affected 0 Records in 2 ms at
org.apache.empire.db.DBDatabase.executeSQL(DBDatabase.java:1427)
INFO [2019/01/17 09:20]: An Error occured. Message is: Updating the record 1
in ... failed. It might have been changed or deleted by another user. at
org.apache.empire.exceptions.EmpireException.log(EmpireException.java:124)
To be clear: I dont think its empire-dbs fault really, but I think it would be
nice if empire-db could prevent that
was (Author: derjan):
[~doebele]
I just had a look at the dumps and did a test-restore.
My production system dump milliseconds in timestamps but my dev system does not:
Production:
-- written by empire-db
=> select update_timestamp from ... where id = 1;
update_timestamp
-------------------------
2018-10-11 14:49:54.129
(1 row)
-- dump
$ pg_dump -h localhost -U ... ... -f test.dump
This dump has in fact 2018-10-11 14:49:54.129 as update timestamp. No problem
here.
Test system:
-- import dump
$ psql -h localhost -U ... -f test.dump
=> select update_timestamp from ... where id = 1;
update_timestamp
-------------------------
2018-10-11 14:49:54.129
(1 Zeile)
imported dump - milliseconds still there.
Trying to update with empire-db:
INFO [2019/01/17 09:20]: Executing: UPDATE ...
SET FOO='BAR', UPDATE_TIMESTAMP='2019-01-17 09:20:16'
WHERE ID=1 AND UPDATE_TIMESTAMP='2018-10-11 14:49:54' at
org.apache.empire.db.DBDatabase.executeSQL(DBDatabase.java:1417)
INFO [2019/01/17 09:20]: executeSQL affected 0 Records in 2 ms at
org.apache.empire.db.DBDatabase.executeSQL(DBDatabase.java:1427)
INFO [2019/01/17 09:20]: An Error occured. Message is: Updating the record 1
in ... failed. It might have been changed or deleted by another user. at
org.apache.empire.exceptions.EmpireException.log(EmpireException.java:124)
To be clear: I dont think its empire-dbs fault really, but I think it would be
nice if empire-db could prevent that
> PreparedStatements not working with MS SQL-Server > 2012
> --------------------------------------------------------
>
> Key: EMPIREDB-283
> URL: https://issues.apache.org/jira/browse/EMPIREDB-283
> Project: Empire-DB
> Issue Type: Bug
> Components: Core
> Affects Versions: empire-db-2.4.4, empire-db-2.4.6, empire-db-2.4.7
> Environment: JAVA 8, WIN2K12R2, MS-SQL-SRV > 2012, JDBC-Driver 4.2,
> 6.0, 7.0
> Reporter: Gunnar Kappei
> Priority: Major
>
> Since the company I'm working at upgraded their database-servers from MS-SQL
> 2012 to 2016, there seems to be an issue when using PreparedsStatements
> together with Empire-DB.
> When enabling PreparedStatements via
> DBDatabase#setPreparedStatementsEnabled(true), it's not possible to perfom
> SQL-UPDATEs.
> Debugging the sources I found out, that the problem is located nside the
> executeSql-method of the DBDatabase / DBDatabaseDriverMSSQL classes. The
> number of affected records is < 0. Therefore an exception is thrown. There is
> no issue with INSERT statements.
> When disabling PreparedStatements, the code is working fine again since it
> did for years now. Tried Empire-DB 2.4.4, 2.4.6, 2.4.7 and several versions
> of the official JDBC driver from MS. On several database-servers. Getting the
> same result every time.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
