Comments
Sort by recent activity
We have also been experiencing this issue for a while now. 2 commits are often required to get the repository updated. / comments
We have also been experiencing this issue for a while now. 2 commits are often required to get the repository updated.
I updated the working base file, updated the SVN file, unlinked, relinked, resolved conflicts. This process added a couple of revisions but got rid of the error on the commit tab. I went to deploy using SQL Compare and got the error again on the checking dependencies step.
I think what's happening in my case is that the the table creation script has the faulty code where the trigger is defined twice and the deployment process is checking that file even though it isn't used in the deployment because it's covered by a migration script.
I don't know of any way to go back and modify files within a previous revision so I told the deployment to skip the migration script, copied the deployment script to SSMS and modified it manually with the neccessary change from the migration script.
NOTE: The migration script was fine but I had to tell SQL Compare to skip it anyway because the underlying object script (unused in deployment) was faulty for that revision / comments
I updated the working base file, updated the SVN file, unlinked, relinked, resolved conflicts. This process added a couple of revisions but got rid of the error on the commit tab. I went to deploy ...
The issue did have to do with Static data. Fortunately for us, the static data feature was just initially evaluated and never really used so I was able to delete the files under the Data folder for this database on the SVN server. It would be interesting to hear what someone would have to do to retain those files and resolve the error in this kind of scenario. / comments
The issue did have to do with Static data. Fortunately for us, the static data feature was just initially evaluated and never really used so I was able to delete the files under the Data folder for...
Version 5.1.4.11
I was using a sysadmin account when I first encountered the error but tried it with another just to be on the safe side. I get the error with either account. / comments
Version 5.1.4.11
I was using a sysadmin account when I first encountered the error but tried it with another just to be on the safe side. I get the error with either account.
I will upgrade but I just figured it out. I noticed that I got no error when connected directly to the SQL2000 server and not attempting to fully qualify objects. When I attempted to fully qualify when directly connected, I got an error about DATA ACCESS not being configured. I set this option to true and all SQL Prompt errors went away. I then connected to my 2008 instance and got the error again. It then dawned on me that the linked server setup on my 2008 server to point to my 2000 server used a specific login account which is not sysadmin. There was my duh moment. When I looked at the role membership for this user on the master database on my 2000 server, I saw that someone has specifically set denydatareader. Unchecked that role, restarted SSMS and all is wonderful now. Thanks for holding my hand / comments
I will upgrade but I just figured it out. I noticed that I got no error when connected directly to the SQL2000 server and not attempting to fully qualify objects. When I attempted to fully qualify ...
I got latest on a fresh db, dropped just those objects that shouldn't have been there, then committed just those drops. Still not sure why it happened in the 1st place but that seemed to work. Thanks for your workaround anyway. / comments
I got latest on a fresh db, dropped just those objects that shouldn't have been there, then committed just those drops. Still not sure why it happened in the 1st place but that seemed to work. Than...
The dropped objects are listed as Adds since the objects were actually dropped in the db but the repo thinks they're still there.
A backup is used because of the complexity of our structure and data. A close to complete data set is needed for testing so a backup is easier than a fresh db and ETL. Either way, the comparison would still create those objects that should no longer actually be in source control because they were dropped and supposedly committed. / comments
The dropped objects are listed as Adds since the objects were actually dropped in the db but the repo thinks they're still there.
A backup is used because of the complexity of our structure and dat...
I wasn't sure if I could just remove the .sql files and everything still be ok. When I 1st set up SQL Source Control, it seemed very particular about setting up it's own structure so I figured any manual intervention would muck things up.
I don't want to start over in the repo because then I lose all of my history. / comments
I wasn't sure if I could just remove the .sql files and everything still be ok. When I 1st set up SQL Source Control, it seemed very particular about setting up it's own structure so I figured any ...
This database has been under source control for several months. There have been many incremental changes committed over this period. I am the only developer. I recently got a new laptop and restored a version of the db to it. I wanted to make sure everything was in sync with what was on our central development server so I committed any changes that weren't already committed, switched to my local machine, linked my restored db to source control and went to get latest. There are objects showing up that have been dropped for some time now.
To answer your questions more directly:
The objects are not the same objects just committed. Since these weren't the objects just committed, I would say anywhere from 1 week to several months between when the drops were committed and when I tried to get latest. There are no other developers linked to the source control location, although I have 2 different machines that I develop on linked to the same place. Unlink and relink does not resolve the issue.
It's basically like a/some commit(s) for dropped objects did not take in source control. / comments
This database has been under source control for several months. There have been many incremental changes committed over this period. I am the only developer. I recently got a new laptop and restore...