Comments
Sort by recent activity
Update: digging in a bit more, it looks like DLM Automation's SDG can't load the project file because the file was created in a newer version of SDG.
Additionally, the version used by DLM doesn't seem to support copying IDENTITY column values when using an existing data source, which is what I'm trying to do.
Is it possible to update the version of SDG being used by DLM Automation? / comments
Update: digging in a bit more, it looks like DLM Automation's SDG can't load the project file because the file was created in a newer version of SDG.
Additionally, the version used by DLM doesn't s...
Thanks Eddie,
I see now that is mostly working - although there is one case that isn't:
One of the tables I want to import has an optional FK to another table that I do not want to import. In the source data there is only one row that has a value in this FK column. I chose the option to "skip the row" if invalid data is encountered, but it doesn't seem to be doing that. Instead, it fails the whole table insert (inserts 0 rows), and all subsequent tables can't be updated because it says "IDENTITY_INSERT is already on for table <failed table>. Cannot perform SET operation for table <subsequent table>".
Any suggestions?
Thanks / comments
Thanks Eddie,
I see now that is mostly working - although there is one case that isn't:
One of the tables I want to import has an optional FK to another table that I do not want to import. In the s...
Version 11.6.1.1686 Professional / comments
Version 11.6.1.1686 Professional
Ah, good to know. However the next challenge seems to be the following error when it tries to generate the deployment script:
Cannot apply: HunkHeader[179,7->179,9]
Any ideas? Thanks / comments
Ah, good to know. However the next challenge seems to be the following error when it tries to generate the deployment script:
Cannot apply: HunkHeader[179,7->179,9]
Any ideas? Thanks
OK, it's been duly added. If anyone wants to vote for this: http://sqltest.uservoice.com/forums/140716-sql-test-forum/suggestions/2428288-automatically-generate-unit-tests / comments
OK, it's been duly added. If anyone wants to vote for this: http://sqltest.uservoice.com/forums/140716-sql-test-forum/suggestions/2428288-automatically-generate-unit-tests
OK, accepting that it is necessary, I'm curious why the results of DBCC PAGE would need to be sent to the errorlog for a compare operation. DBCC TRACEON 3604 should route the results back to SQL Compare's connection, right? Would that mean that a DBCC PAGE is being issued with 3604 off?
Thanks / comments
OK, accepting that it is necessary, I'm curious why the results of DBCC PAGE would need to be sent to the errorlog for a compare operation. DBCC TRACEON 3604 should route the results back to SQL Co...
Sure enough for some reason 3605 was set globally, though I can't think why... turned it off.
I'll try it again with the option enabled and see if that fixes it. Thanks
Edit: Sure enough, that was the culprit - a compare operation that previously logged > 787 MB just finished at < 3MB. Thanks for the pointer! / comments
Sure enough for some reason 3605 was set globally, though I can't think why... turned it off.
I'll try it again with the option enabled and see if that fixes it. Thanks
Edit: Sure enough, that was ...
Hi Mark, currently SQL Compare is set to "No Logging" so I have no SC-generated logs. To be clear, the logs I am talking about are the SQL Server error log files, the ones which can be found by going to Management > SQL Server Logs in SSMS.
Elsewhere in the forums I came across this post from several years and many versions ago which may be related? I'm definitely seeing "DBCC 3604 ON" and "DBCC 3604 OFF" in the logs. https://forums.red-gate.com/viewtopic.php?t=10817 / comments
Hi Mark, currently SQL Compare is set to "No Logging" so I have no SC-generated logs. To be clear, the logs I am talking about are the SQL Server error log files, the ones which can be found by goi...
Any update on this request? We've been running into the same issue.
In regards to the directions given above ("you would typically use SQL Data Compare to deploy the changes"), I have to disagree. The whole point of linking static data is to essentially elevate certain tables to the same importance as schema for the purpose of deployments.
To then exclude these same tables from the main deployment channel (SQL Compare) is just broken. (Especially given that this has been recognised as an issue and addressed for command-line!)
Can this be added as an option for UI?
Thanks / comments
Any update on this request? We've been running into the same issue.
In regards to the directions given above ("you would typically use SQL Data Compare to deploy the changes"), I have to disagree. ...