Comments
Sort by recent activity
Hi Iain,
I've just had a look at this myself. I do see the same behaviour as you (I think!) - the migration script in the repo has a terminating 'GO' but when we execute the script on a Get Latest, the GO seems to be omitted. Interestingly, in my case, this didn't stop the extended properties from getting updated so I'm not sure that the cause of that is necessarily the same.
In any case, I'll log a bug for that, although I'm not sure as to the likelihood of it getting resolved. This is because we're re-working the whole migrations function which will work completely differently (see here for details) / comments
Hi Iain,
I've just had a look at this myself. I do see the same behaviour as you (I think!) - the migration script in the repo has a terminating 'GO' but when we execute the script on a Get Latest,...
Hi Randy,
Yes, that's right. In short, the folder you link to should contain *only* files related to that specific database. If you link to a folder higher up the tree, we will parse all subfolders and you'll either see objects you weren't expecting (as in your case), or alternatively the tool may throw 'duplicate object definition' errors.
Hope that helps! / comments
Hi Randy,
Yes, that's right. In short, the folder you link to should contain *only* files related to that specific database. If you link to a folder higher up the tree, we will parse all subfolders...
Thanks for your post- I checked our bugtracker, and this kind of message has come up previously, although only very occasionally.
One user observed that they fixed it with the following process:
Problem occoured on an initial commit from my database to an empty source control location. I've figured it out - problem was caused by SVN settings located in %APPDATA%\Subversion\config file. 'enable-auto-props' setting was set to 'yes'. Changing it to 'no' solved my problem.
Could you maybe see if that helps in your case? We don't expose the actual setting anywhere (we use the SharpSVN library, which I believe should honour whatever is configured locally via Tortoise etc.) / comments
Thanks for your post- I checked our bugtracker, and this kind of message has come up previously, although only very occasionally.
One user observed that they fixed it with the following process:
P...
Hi Bret, thanks for your post, and sorry you are having some trouble. The underlying error as you probably saw is:
Fulltext index references unknown key index PK__Document__5A5B77D507C43B0B
The first thing to establish is if this is something odd in your database or your scripts - to do this, try unlinking your database, then link it to an "evaluation" repository and perform a commit of all the objects. If that works, then the problem is probably in the script files; my guess being they have some sort of inconsistency in.
You can try checking out a copy of the scripts from your repo to a temporary folder and then running a command prompt "findstr" command to locate where the reference is, for example:
findstr /S /C:"PK__Document__5A5B77D507C43B0B" *.*
That will hopefully find the file where the fulltext index is referencing that key. If no other reference is found, then it's likely that the PK on whichever table it references is now different.
As you're using system named constraint names rather than explicit ones, it could be that the problem was caused by someone committing a change to the underlying table which resulted in a new PK name, but not the Fulltext index (which in theory should have been shown as a dependency to be committed)
To correct the problem, you'd ideally need to work out what the correct PK name now is, update the file for the fulltext index to match that, then unlink and relink your DB to refresh the working copies. / comments
Hi Bret, thanks for your post, and sorry you are having some trouble. The underlying error as you probably saw is:
Fulltext index references unknown key index PK__Document__5A5B77D507C43B0B
The fir...
We don't store indexes in their own files, they are stored in the file for the table to which they relate.
In any case, you don't need to worry about the folder structure we use for storing the scripts (indeed, manually changing these can lead to unpredictable behaviour).
Simply modify your DB using SSMS as normal and commit the changes, and the relevant files in TFS will get updated.
Hope that helps / comments
We don't store indexes in their own files, they are stored in the file for the table to which they relate.
In any case, you don't need to worry about the folder structure we use for storing the scr...
OK, I managed to reproduce this in the end. The important part seemed to be in step 5- the further adjustments only triggered the problem when they were a change to an object that had been previously committed.
Once I got the error I could resolve it by going to the Working Base on the newly linked DB (right click the URL on the SQL Source Control setup tab) and pick "Open Working Base"), then right clicking the 'Tables' folder (this will probably work if you just do the parent folder with the random name) then did an SVN Update.
Once I did that, I refreshed the commit tab, tried again, and it went though.
My guess is that the combination of the restored DB along with the "copy" in SVN somehow gets things out of kilter although I'm not sure exactly how yet... any SVN experts? / comments
OK, I managed to reproduce this in the end. The important part seemed to be in step 5- the further adjustments only triggered the problem when they were a change to an object that had been previou...
My guess would be that you'd want to source control the CLR function first so it's available in target databases.
You could then commit your table change but override it with a migration script to execute your CLR function to update the data before changing the column type.
If you're not using migrations, then you'd probably be better off manually running the function to update the data, then getting the column change from source control afterwards? / comments
My guess would be that you'd want to source control the CLR function first so it's available in target databases.
You could then commit your table change but override it with a migration script to ...
Thanks
I created the table, and then inserted the data. I was able to add this into SQL Source Control without any problem though.
Do you have trouble when committing? Or do you have problems with existing files .sql from somewhere else? / comments
Thanks
I created the table, and then inserted the data. I was able to add this into SQL Source Control without any problem though.
Do you have trouble when committing? Or do you have problems with ...
I'm afraid I'm not really sure what the problem is here. Do you get an error message? Please can you send over a table definition and insert statement so we can replicate the problem?
It might well be a bug with extended character-sets but I've not heard of it happening before so I'd like to see if I can reproduce the problem. / comments
I'm afraid I'm not really sure what the problem is here. Do you get an error message? Please can you send over a table definition and insert statement so we can replicate the problem?
It might well...
Thanks for your post, and sorry you're having trouble.
I don't immediately know what would cause this, but it's possibly that some of the syntax in your code makes our tool have a problem (I've seen a couple of similar instances recently)
It would be helpful if you could pick the option to "send error report" when the crash happens, and make sure you put your email address in the box provided so I can find it in the system here. This should give us some further clues as to what may be the cause. / comments
Thanks for your post, and sorry you're having trouble.
I don't immediately know what would cause this, but it's possibly that some of the syntax in your code makes our tool have a problem (I've see...