headToWorkingbase didn't get set

Deep

I started getting this error again in SQL Source Control version  version 7.2.20.12234
Error message: "headToWorkingbase didn't get set"
I did unlink and link again to the GIT repository, Still getting error.
Please provide a resolution ASAP, as this is a production database 

Deep

Just removing the files from transient folder as suggested by Redgate earlier was not working. 

The following process worked: Unlink Source code control; Remove the files (that were showing up as duplicate files in the logs) from the local repository and then commit the change to GitHub to remove the files from GitHub, and then link source code control. 

I still do not understand why removing a table and creating view with same name caused Redgate SQL Source Control to go Topsy Turvy, while the operation was valid for the database. Suggesting to start a new repository was a bad idea, as we would lose all the change history. Please get to the root cause of the problem to resolve this for future. 

After that resolution, hundreds of objects appeared as Change Type “Conflict”,  I had to select each one to set “Keep Mine”. Why can’t I bulk select and set “Keep Mine”? The product seems very unstable, and needs some serious updates, especially the version to work with GitHub.

 

 

Deep

Just removing the files from transient folder as suggested by Redgate earlier was not working. 

The following process worked: Unlink Source code control; Remove the files (that were showing up as duplicate files in the logs) from the local repository and then commit the change to GitHub to remove the files from GitHub, and then link source code control. 

I still do not understand why removing a table and creating view with same name caused Redgate SQL Source Control to go Topsy Turvy, while the operation was valid for the database. Suggesting to start a new repository was a bad idea, as we would lose all the change history. Please get to the root cause of the problem to resolve this for future. 

After that resolution, hundreds of objects appeared as Change Type “Conflict”,  I had to select each one to set “Keep Mine”. Why can’t I bulk select and set “Keep Mine”? The product seems very unstable, and needs some serious updates, especially the version to work with GitHub.

Jon_Kirkwood

Hi there, 

Thanks for reaching out over the Redgate forums and sorry to hear about issues with SQL Source Control.

The headToWorkingbase didn't get set error is often an error that triggers from a few different possible underlying errors.

Are you able to enable & access the log files and provide a copy of the log to Redgate.

SQL Source Control - Access log files

Otherwise, you can search in the log file for the headToWorkingbase string to see what is triggering the error, it will likely have some details like this

<p>System.InvalidOperationException: headToWorkingBase didn't get set RedGate.SQLCompare.Engine.DupIicateObjectNameException:&nbsp;</p><p>A duplicate definition was found for the column&nbsp;<b>[dbo].[table].[value]</b></p>

If there is a duplicate definition error then it would be recommended to conduct a comparison between tables in your target & local databases to locate potential differences in this column. We have seen common examples of this error being a duplicate CREATE statement referencing the object which is causing the error.

This link may also help with troubleshooting the error message to clear the issue and allow a clean commit to occur.
Duplicate definition troubleshooting in SQL Source Control

If this doesn't assist with solving your issue our next step is to request the log file & zipped copies of your Working Base and Transient Folders of the database where you are experiencing the issue so we can investigate further. If you don't wish to submit them over the forum we can provide a private file-sharing link.

Deep

I looked in the logs and also in my repository. All the objects that show RedGate.SQLCompare.Engine.DuplicateObjectNameException have only one copy in the GitHub repository and have been checked in by me using SQL Source Control. I am attaching logs, working base and transient files zip files as requested. Please help resolve this ASAP.

Deep

logs file attached

Deep

transient file attached

Jon_Kirkwood

Thank you for providing the files.

I note errors on 5 items in the logs provided;

member.DimMemberFlags.MemberFlagsKey
member.FactMemberShipCancel.GroupKey
member.FactMembershipActive.GroupKey
member.DimMemberCodes.MemberCodesKey
member.DimMemberFlags.MemberFlagsKey

Looking at each of these I can see a Table & View with the same name being created within your Transient folder which is what I suspect is throwing the error as views & tables can't share the same name.

If this is looking like the suspected issue then please test changing the name of the view/table to be unique and try a new commit.

This screenshot is a comparison of file member.FactMembershipActive.SQL in both your table & view folders

Let me know if this helps resolve this issue or we need to keep digging.

Deep

The names of tables and views are not same. That's not even possible in the same database. The Tables have a 'TBL' postfix and the views are without that. This is our naming convention from the very beginning. All tables and views are named that way,  and SSC was working with it. I suspects the problem to be something else. Please set up a meeting so you can look into it and resolve quickly. I have attached the snapshots in a zip folder to show the mane differences.

Deep

Can I get an appointment this today? I am available 3 pm est onwards or between 10 am est and noon..

Deep

Here is what I found. Please let me know how I can resolve this, and why this is an issue. 

All of the objects copied below were tables in the old legacy model. We did some re-modeling and created new objects using our standard naming convention.  Now the tables have a postfix ‘Tbl’ with the same name and they each have a view without the ‘Tbl’.  I think that is causing the duplicate file issue.

This change is valid in the database, so why does Redgate have an issue with this. The old tables are in ‘Tables’ folder and the new views with same name are in the ‘Views’ folder. Why is it comparing tables with views? 

Old model tables:

member.DimMemberFlags
member.FactMemberShipCancel
member.FactMembershipActive
member.DimMemberCodes

 

New Model tables:

member.DimMemberFlagsTbl
member.FactMemberShipCancelTbl
member.FactMembershipActiveTbl
member.DimMemberCodesTbl

 

New Model views:

member.DimMemberFlags
member.FactMemberShipCancel
member.FactMembershipActive
member.DimMemberCodes

Jon_Kirkwood

Hi,

Thanks for your patience whilst we look into this.

The error logs do indicate that object names are being reused. 

Inside your Transient/Tables folder there are files such as 

member.DimMemberFlags.sql
& 
member.DimMemberFlagsTbl.sql

Can you please verify that both of these files should exist.
With your recent info, it does seem possible that the old tables code are still there in the repo along with the new table code.
This is a potential cause of the duplicate definitions.

To test this can you please remove these files and see if the error message persists:

Transient/Tables folder
member.DimMemberFlags.sql
member.FactMembershipActive.sql
member.FactMembershipCancel.sql
member.DimMemberCodes.sql

Deep

As suggested, I have deleted the following files from the transient folder. I double checkd the transient folder for all these files after deletion and di not find them. Bur when I re-run the Commit for KPGA_DWH database, the files come back and I still get the same error. Still waiting for a resolution to this problem.

A table can be dropped in a database, and a view can be created by the same name, as the table that was dropped. Why can't Redgate SSC handle this?

Files deleted from Transient/Tables folder
member.DimMemberFlags.sql
member.FactMembershipActive.sql
member.FactMembershipCancel.sql
member.FactMembershipBroker.sql
member.DimMemberCodes.sql

Deep

I have been waiting for a response on the=is for a while now. Can you please have an expert look into it, so the issue can be resolved. How can I schedule a working session so we can try all that we can to resolve this ASAP?

Jon_Kirkwood

Hi and thank you for your patience with the timeline on this inquiry.

This has been escalated within our technical support team for further assistance into why this duplicate object error keeps persisting.

There is a ticket raised against this post which we will communicate against for the next steps including the process to schedule a working session to resolve this issue.

Deep

Just removing the files from transient folder as suggested by Redgate earlier was not working. 

The following process worked: Unlink Source code control; Remove the files (that were showing up as duplicate files in the logs) from the local repository and then commit the change to GitHub to remove the files from GitHub, and then link source code control. 

I still do not understand why removing a table and creating view with same name caused Redgate SQL Source Control to go Topsy Turvy, while the operation was valid for the database. Suggesting to start a new repository was a bad idea, as we would lose all the change history. Please get to the root cause of the problem to resolve this for future. 

After that resolution, hundreds of objects appeared as Change Type “Conflict”,  I had to select each one to set “Keep Mine”. Why can’t I bulk select and set “Keep Mine”? The product seems very unstable, and needs some serious updates, especially the version to work with GitHub.