Skip to content
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

SQL Server USE statements within migration cause Flyway to fail #1676

Closed
mahidbdw opened this issue Jun 19, 2017 · 6 comments
Closed

SQL Server USE statements within migration cause Flyway to fail #1676

mahidbdw opened this issue Jun 19, 2017 · 6 comments

Comments

@mahidbdw
Copy link

@mahidbdw mahidbdw commented Jun 19, 2017

What version of Flyway are you using?

4.2.0 (flyway-commandline-4.2.0-windows-x64.zip)

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Command-line

What database are you using (type & version)?

SQL server 2012 (express edition)

What operating system are you using?

Windows 7 professional SP1

What did you do?

(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
My scripts were running with flyway 4.0 command-line without issue.
Then I use flywayclean. And dropped DB. Created new DB. And then used flyway 4.2.0 with migrate.
But the same scripts failing when I am using 4.2.0 version even though there are no rows in that table.

What did you expect to see?

Should not raise Violation of PRIMARY KEY error, when there are no rows in that table.

What did you see instead?

SQL State : 23000
Error Code : 2627
Message : Violation of PRIMARY KEY constraint 'property_PRIMARY_property'. Cannot insert duplicate key in object 'dbo.property'.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jun 19, 2017

Please provide the smallest possible SQL file that reproduces the issue.

@mahidbdw
Copy link
Author

@mahidbdw mahidbdw commented Jun 20, 2017

pk_issue.zip
Plz note: This is sample script, just to reproduce the issue.

1st file uses: 2 databases, it just creates tables. No insert.
2nd file: has only 1 insert.
And this PK error is occuring on 2nd file.
It works fine with 4.0.
But getting error with 4.2.0.

Do let me know your observation.

@mahidbdw
Copy link
Author

@mahidbdw mahidbdw commented Jul 14, 2017

Any update on this.
It would be helpful if you can update on this.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jul 14, 2017

We haven't had time to look into this and nobody else seems to be having the issue so far. You are of course welcome subscribe to one of our support plans and we would be happy to investigate immediately or alternatively you could roll up your sleeves and crack open the debugger to find out what is going on.

@rogatec
Copy link

@rogatec rogatec commented Jul 25, 2017

I've run into this error also today.

I "fixed" this problem temporarily by:

  1. removing the table with the primary key violation from the database.
  2. then I created a script file which includes schema and data. (of the evil table 😈 )
  3. migrated with flyway without any errors.
@axelfontaine axelfontaine added the t: bug label Nov 27, 2017
@axelfontaine axelfontaine added this to the Flyway 5.1.0 milestone Nov 27, 2017
@axelfontaine axelfontaine changed the title Violation of PRIMARY KEY constraint SQL Server USE statements within migration cause Flyway to fail Dec 18, 2017
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Dec 18, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 18, 2017

This is now fixed. Flyway now properly deals with migration scripts changing the current database.

dohrayme pushed a commit to dohrayme/flyway that referenced this issue Feb 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.