Comments
5 comments
-
This is also happening to us as well.
We have 4 developers all working in a shared "staging" database. If I try to link to a repository folder that was created by a different user I get similar errors. -
I also get that kind of error (mailed it already to the SQL Source Control support address). Seems it crashes if it cannot find the table referenced by foreign keys...in my case the target table isn't in version control and this prevents me from adding new ones or commit existing ones...
my stack
Failed to update:
#oEc.#8Jf: Failed to locate the target table [dbo].[ASPA_MAKSULAJIREKISTERI] for the FK_LAINA_LAINAKORTTIMAKSULAJIT_MAKSULAJIT foreign key. ---> RedGate.SQLCompare.Engine.SqlCompareException: Failed to locate the target table [dbo].[ASPA_MAKSULAJIREKISTERI] for the FK_LAINA_LAINAKORTTIMAKSULAJIT_MAKSULAJIT foreign key. ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1435, offset:37 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 211, offset:38 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1369, offset:0 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 210, offset:30 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 213, offset:38 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 773, offset:61 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 757, offset:31 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 771, offset:14 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1514, offset:36 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1357, offset:63 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 165, offset:468 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1507, offset:800 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1373, offset:18 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 211, offset:38 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 215, offset:38 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1205, offset:143 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1204, offset:6 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 958, offset:31 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 956, offset:0 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1453, offset:0 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1359, offset:117 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 149, offset:11 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 186, offset:137 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 930, offset:22 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1633, offset:31 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1002, offset:500 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1006, offset:109 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1008, offset:22 ---> SmartAssembly.SmartExceptionsCore.UnhandledException: SmartExceptionsCore.UnhandledException @ 1010, offset:13
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
at #oEc.#7Jf.#t.#B3.#sKf()
at #oEc.#7Jf.#gKf(Action action)
--- End of inner exception stack trace ---
Server stack trace:
at #eEc.#fEc.#t.#izb.#j5f()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at RedGate.SQLSourceControl.CommonUI.Forms.ErrorDialog.DoWithObviousExceptionsThrowAll(Action action)
at #JLc.#PLc.#CTc(ICancellableOperation`1 operation, Object token) -
Thank you for reporting this issue. We are aware that there are problems sometimes when you do not start from an empty database. This is because we try to match objects that are exactly the same and update your revision number with the objects that match. If there is a FK relationship and we haven't updated the referenced table, then you get into this state.
WORKAROUND:
The only workaround we can currently suggest is to link a brand new database. Then get latest, so you are in the latest state. You can then use SQL Data Compare to copy all your data from the original database to this new database. And SQL Compare, if you had any schema changes in your original database that you want to make and then commit to source control
I hope this helps for now. I will update as soon as I know we have a fix. -
There's another situation that could cause this issue. It could happen if you commit an object, but do not commit its dependencies. This causes the version in source control to be in an invalid state, which we then have trouble parsing. You should be warned if there are dependencies when committing or getting and it is checked by default to include these.
Creating a new db and relinking does NOT help in this case.
WORKAROUND:
1) If you don’t have a lot of history in source control that you care about since this is an evaluation, then it might be better to just DELETE everything in source control and start again. This time when you commit an object, include its dependencies and hopefully you will get pass this issue.
2) If you want to keep your current history, do you have SQL Compare Pro? If so, you could script TableA to a scripts folder and then commit this to the Tables directory in SVN using TortoiseSVN. This should put the source control version back in a “valid†state and let you continue. If you don’t have SQL Compare Pro, script out the table using SSMS, and then Commit to SVN, but make sure it is named owner.tablename.sql like the other files are named. -
Don't count on SQL Compare Pro as a workaround. I'm getting the
"failed to locate the target table" error in SQL Compare Pro.
This is happening to me on several tables. It's rendering SQL Compare Pro unusable for source control (the whole reason for buying Pro).
Environment: Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )
Failures all occur on foreign keys for tables in a schema other than dbo, and referencing tables in that same (non-dbo) schema.sherr wrote:There's another situation that could cause this issue. It could happen if you commit an object, but do not commit its dependencies. This causes the version in source control to be in an invalid state, which we then have trouble parsing. You should be warned if there are dependencies when committing or getting and it is checked by default to include these.
Creating a new db and relinking does NOT help in this case.
WORKAROUND:
1) If you don’t have a lot of history in source control that you care about since this is an evaluation, then it might be better to just DELETE everything in source control and start again. This time when you commit an object, include its dependencies and hopefully you will get pass this issue.
2) If you want to keep your current history, do you have SQL Compare Pro? If so, you could script TableA to a scripts folder and then commit this to the Tables directory in SVN using TortoiseSVN. This should put the source control version back in a “valid†state and let you continue. If you don’t have SQL Compare Pro, script out the table using SSMS, and then Commit to SVN, but make sure it is named owner.tablename.sql like the other files are named.
Add comment
Please sign in to leave a comment.
Things got dicey, though when another user, accessing the same database tried to connect. We get error messages (See Below).
I get the same kinds of errors when I try to attach to a different databsae that he initialized.
I'm wondering if the problem is that we are working with the same instance of the database, in the same directory of subversion, but from different workstations?
Or is there some other bug happening here?