Comments
Sort by recent activity
Didn't exactly work for me because the migration script seemed to have gotten "disconnected" from the object: when another user did a get-latest on the table it didn't pull the migration script, and the table's schema change failed. The migration script included SQL INSERT statements to properly populate the temporary table created with the new NOT NULL columns I added.
I guess because of the manual edit I performed on the .SQL file for the table (in TFS).
Bummer. / comments
Didn't exactly work for me because the migration script seemed to have gotten "disconnected" from the object: when another user did a get-latest on the table it didn't pull the migration script, an...
adriancearnau wrote:
I think I can replicate this problem easily.
Every time I reorder the columns in a table with triggers and then commit a migration script with the modifications, the table definition SQL file gets modified and includes the same triggers twice.
If there are also trigger modifications caught in the migration script, the table definition file ends up containing both the previous and the current trigger definitions.
This is quite a nasty regression, I haven't had this problem in previous versions of SQL Source Control. Any idea where I could report this bug properly?
By the way, thanks a lot for the Ctrl+Shift tip, didn't know I can access the working base folder like that, always had to rummage through AppData before.
Exact same problem here. Table with a trigger, added two fields, modified the trigger, and used a migration script to encapsulate the changes.
The issue isn't a SQL script error, it's an error in the processor that's creating the script. I suspect it's actually a SQL Compare issue... / comments
adriancearnau wrote:
I think I can replicate this problem easily.
Every time I reorder the columns in a table with triggers and then commit a migration script with the modifications, the table d...
Here is what I did to get my environment back to a usable state:
1) After committing the change (mine was via a migration script), I went into the WorkingBases folder, found the modified table file (sort by date is easiest), made it not Read-only, edited the file to remove the extra trigger definition. Save the file.
2) Manually check out and perform the same edit on the file in actual TFS Tables folder. Check in this change.
3) In SQL Source Control, un-link my database. Ignore any errors that occur ("folder is not empty"). Close SSMS.
4) Re-open SSMS and link the database again. / comments
Here is what I did to get my environment back to a usable state:
1) After committing the change (mine was via a migration script), I went into the WorkingBases folder, found the modified table file...
This seems related to an issue I'm having with restoring from a database which is essentially a copy of the database I used to perform the initial commit, but which doesn't have any SQL Source Control information stored.
See http://www.red-gate.com/MessageBoard/viewtopic.php?t=15886 / comments
This seems related to an issue I'm having with restoring from a database which is essentially a copy of the database I used to perform the initial commit, but which doesn't have any SQL Source Cont...
After we do our restore from "Production" and run some schema scripts which cover items not in source control, we use SQL Compare.
Comparing "from" the Source Control latest version "to" the restored database and letting SQL Compare deploy the changes seems to clear everything up.
When we go to the SQL Source Control window in SSMS, it's "clean" (nothing on Commit Changes, nothing on Get Latest). / comments
After we do our restore from "Production" and run some schema scripts which cover items not in source control, we use SQL Compare.
Comparing "from" the Source Control latest version "to" the restor...
Thanks Pete.
One question: will all of this unlinking/re-linking cause an explosion of files in our local TFS workspaces?
One thing I noticed when I was evaluating SQL Source Control prior to our purchase of the product was that there seemed to be an inordinate number of local TFS workspaces created.
Thanks again,
Craig / comments
Thanks Pete.
One question: will all of this unlinking/re-linking cause an explosion of files in our local TFS workspaces?
One thing I noticed when I was evaluating SQL Source Control prior to our p...
The database being restored doesn't have any of the extended properties.
I had thought of this as a solution, so as part of the restore I went ahead and set the extended properties (SQLSourceControl Database Revision, SQLSourceControl Scripts Location, and SQLSourceControl Migration Scripts Location), setting the Revision value to the value of the revision when I did my initial commit.
This only seemed to make things worse, though. / comments
The database being restored doesn't have any of the extended properties.
I had thought of this as a solution, so as part of the restore I went ahead and set the extended properties (SQLSourceContro...
eddie davis wrote:
Hi,
The command line for this option is one of the following:
/Options:DisableSOCForLiveDBs
Or using the alias
/Options:dafld
Full list of the Command Line Options can be found HERE.
Many Thanks
Eddie
That option works great! Thanks! / comments
eddie davis wrote:
Hi,
The command line for this option is one of the following:
/Options:DisableSOCForLiveDBs
Or using the alias
/Options:dafld
Full list of the Command Line Options can be f...
mmoore wrote:
After looking further into this, I noticed that this only applies to the Extended Properties that are added by SQL Source Control. They are always added, which in my case is pointless on my customer's Sql Server.
I don't think that's the case. I check-boxed this option in the "Ignore" section and still had the SQL Source Control version number update appear in the deployment script.
I would LOVE LOVE LOVE to not have to manually edit my script every time I deploy to an environment that's not under SQL Source Control, especially since those environments aren't always updated to the LATEST in our repository (we selectively deploy objects to the target environment). / comments
mmoore wrote:
After looking further into this, I noticed that this only applies to the Extended Properties that are added by SQL Source Control. They are always added, which in my case is pointl...
I am definitely in the camp of wanting to specify SPECIFIC foreign key values. / comments
I am definitely in the camp of wanting to specify SPECIFIC foreign key values.