Comments
Sort by recent activity
@Groucho You're The They! I deleted the file that was causing the error in both the Transients and WorkingBases folder and it worked. For anyone else looking to resolve this issue (seems to be a fairly regular occurrence), these are the exact steps I took to resolve the issue: I inspected my Transients, WorkingBases and my local repo for the file causing the error. Oddly, WorkingBases didn't have any of the objects Transients and my local repo had. I deleted the file causing the error message in Transients and for my local repo, simply moved the file into a directory one step higher. I then closed all my SSMS windows, then started a fresh SSMS instance (there is caching involved with SQL Source Control). I then right-clicked the database with Source Control enabled and clicked "Commit to Source Control". I was then greeted with another error. The same error and same file, but in the WorkingBases folder. I checked the WorkingBases folder and found all my objects were in fact there this time. I deleted the file causing the error in WorkingBases and closed all of my SSMS windows, then started a fresh SSMS instance. I then right-clicked the same database, clicked "Commit to Source Control" waited with angst and excitement for the registration of the database and it then completed and offered me to commit my change to source control. Commits were without hiccup, as well as committing changes to repo in Azure DevOps. Thank you, kind They! / comments
@Groucho You're The They!I deleted the file that was causing the error in both the Transients and WorkingBases folder and it worked.For anyone else looking to resolve this issue (seems to be a fair...
I'm experiencing this same issue for a stored procedure file in the Transients localappdata folder for Sql Source Control 7. I'm unable to "Get Latest" nor "Commit". Thanks! / comments
I'm experiencing this same issue for a stored procedure file in the Transients localappdata folder for Sql Source Control 7.I'm unable to "Get Latest" nor "Commit". Thanks!
Did you ever receive an answer or resolve your question? I'm attempting to rebaseline due to developments already applied to my target and those being incorporated in the development database, already. (I was in the process of setting up SCA and feature improvements were still being implemented, so here I am). It seems it would be easier to either start a new sqlproj (which I'm less inclined to do), or rebaseline (which seems more manageable given a multiple user architecture). I'm not seeing much in terms of rebaselining other than "cloning" a lower environment with some potential data missing and switching the the databases by doing a rename. However, I am curious about your question and what you did to resolve it, if this is something I may need to consider in the future. Thank you! / comments
Did you ever receive an answer or resolve your question?I'm attempting to rebaseline due to developments already applied to my target and those being incorporated in the development database, alrea...