Liquibase Community Forum
2010-10-20 00:02:55 UTC
A new topic, 'DATABASECHANGELOGLOCK is created twice on case-sensitive MS SQL database', has been made on a board you are watching.
You can see it at
http://liquibase.org/forum/index.php?topic=749.new#new
The text of the topic is shown below:
Hi,
When I run Liquibase 2.0 RC7 (revision 1786) against a database that has not been managed by Liquibase yet, it errors out early in the process (log snippet below). Subsequent runs error out in different ways, depending on whether the tables exist and what command is used, so I'll just focus on the simplest case.
My setup:
- I've built a recent snapshot of 2.0 RC7 (revision 1786) using Maven 3.0 (command at end of post).
- The database and server are case-sensitive (SQL Server 2008 SP1, database and server collation set to Latin1_General_BIN)
- The database in this test does not have a DATABASECHANGELOG or DATABASECHANGELOGLOCK table.
- When I run Liquibase with the "status" command against my testing XML files, it errors out with:
liquibase:INFO: Successfully acquired change log lock
liquibase:INFO: Creating database history table with name: [dbo].[DATABASECHANGELOG]
liquibase:INFO: There is already an object named 'DATABASECHANGELOGLOCK' in the database.
- Looking at a SQL trace, I see that the "DATABASECHANGELOGLOCK" table is created early on, but then a prepared SQL statement is run, using the sp_tables procedure to check for the existence of "databasechangeloglock". A subsequent attempt to create "DATABASECHANGELOGLOCK" again fails with the error.
- Based on some ad-hoc testing, I believe the same situation will occur for the DATABASECHANGELOG table.
- If I run modifications like the following, these errors go away and the app works as expected. I'm guessing the app consistently reads/writes with the capitalized table names but just checks for existence with the lower-case names.
select *
into databasechangeloglock
from DATABASECHANGELOGLOCK
where 1 = 0
go
select *
into databasechangelog
from DATABASECHANGELOG
where 1 = 0
go
delete DATABASECHANGELOGLOCK where 1 = 1
go
INSERT INTO [dbo].[DATABASECHANGELOGLOCK] ([ID], [LOCKED]) VALUES (1, 0)
go
Thanks for your attention, I am looking forward to 2.0 :)
Trevor
p.s. I built 2.0 RC7 using the command: mvn install -Dmaven.test.skip.exec=true
...which I found on one forum posting. Hope that was the correct way to do it and isn't causing this problem. I did receive some Maven warnings, although the process completed and Liquibase JAR runs.
Unsubscribe to new topics from this board by clicking here: http://liquibase.org/forum/index.php?action=notifyboard;board=1.0
Regards,
The Liquibase Community Forum Team.
You can see it at
http://liquibase.org/forum/index.php?topic=749.new#new
The text of the topic is shown below:
Hi,
When I run Liquibase 2.0 RC7 (revision 1786) against a database that has not been managed by Liquibase yet, it errors out early in the process (log snippet below). Subsequent runs error out in different ways, depending on whether the tables exist and what command is used, so I'll just focus on the simplest case.
My setup:
- I've built a recent snapshot of 2.0 RC7 (revision 1786) using Maven 3.0 (command at end of post).
- The database and server are case-sensitive (SQL Server 2008 SP1, database and server collation set to Latin1_General_BIN)
- The database in this test does not have a DATABASECHANGELOG or DATABASECHANGELOGLOCK table.
- When I run Liquibase with the "status" command against my testing XML files, it errors out with:
liquibase:INFO: Successfully acquired change log lock
liquibase:INFO: Creating database history table with name: [dbo].[DATABASECHANGELOG]
liquibase:INFO: There is already an object named 'DATABASECHANGELOGLOCK' in the database.
- Looking at a SQL trace, I see that the "DATABASECHANGELOGLOCK" table is created early on, but then a prepared SQL statement is run, using the sp_tables procedure to check for the existence of "databasechangeloglock". A subsequent attempt to create "DATABASECHANGELOGLOCK" again fails with the error.
- Based on some ad-hoc testing, I believe the same situation will occur for the DATABASECHANGELOG table.
- If I run modifications like the following, these errors go away and the app works as expected. I'm guessing the app consistently reads/writes with the capitalized table names but just checks for existence with the lower-case names.
select *
into databasechangeloglock
from DATABASECHANGELOGLOCK
where 1 = 0
go
select *
into databasechangelog
from DATABASECHANGELOG
where 1 = 0
go
delete DATABASECHANGELOGLOCK where 1 = 1
go
INSERT INTO [dbo].[DATABASECHANGELOGLOCK] ([ID], [LOCKED]) VALUES (1, 0)
go
Thanks for your attention, I am looking forward to 2.0 :)
Trevor
p.s. I built 2.0 RC7 using the command: mvn install -Dmaven.test.skip.exec=true
...which I found on one forum posting. Hope that was the correct way to do it and isn't causing this problem. I did receive some Maven warnings, although the process completed and Liquibase JAR runs.
Unsubscribe to new topics from this board by clicking here: http://liquibase.org/forum/index.php?action=notifyboard;board=1.0
Regards,
The Liquibase Community Forum Team.