How can we help you today? How can we help you today?
rdaunce

Activity overview

Latest activity by rdaunce

I'm just another forum user, so I can't update anything.  I'm sure someone at Red Gate reviews these, though. I haven't seen the SQL Prompt slow cache message recently, but I know what you are talking about.  SQL Prompt runs queries behind the scenes that query database schema and metadata.  The results of these queries are cached on your local computer and SQL Prompt uses that local cache when it needs any of that information.  If those initial queries are taking longer than expected then the error message is displayed.  If you were seeing that message prior to your issue then that might be a symptom of resource utilization or blocking issues on the SQL Server instance.  If your issue was resolved with the command you ran then it was likely caused by a bad (resource intensive) plan in plan cache that SQL Server maintains and stores on the SQL Server instance.  This is a different cache and is not related to the SQL Prompt cache on your local computer. The command you ran is not specific to SQL Prompt or Red Gate - it's a SQL Server command.  If you run it with no parameters that target a specific cached object then it will remove everything from the plan cache on the SQL Server instance you are connected to.  It should be used with caution, especially it in a production environment, unless you understand the what it does and the potential issues it might cause.  The best way to handle your situation would have been to identify the bad plan(s) and only remove the specific plan from the cache. / comments
I'm just another forum user, so I can't update anything.  I'm sure someone at Red Gate reviews these, though.I haven't seen the SQL Prompt slow cache message recently, but I know what you are talki...
0 votes
Thanks for confirming that there was a change in behavior. My specific use case is cloning the working version in a pre-commit hook on the SQL Source Control repository.  Once the clone is made, the pre-commit hook can perform validation and other operations can on the clone without unwanted side effects in the actual git repository.  For example, I can validate that naming conventions are followed, or that consistent formatting is applied. If the hook identifies and corrects something, it copies it back to the original repository and the updated version is committed. Almost all of our per-commit hook script can be work on using a copy of the contents of the directory instead of having SQL Data Compare create the script folder.  The one thing copying doesn't handle is applying consistent ordering of static data in the cloned version's creation scripts.  In the scripts created by SQL Source Control, the order of the insert statements is inconsistent.  In a commit to SQL Source Control involving static data, the commit frequently moves unchanged rows to different locations in the creation script and moves updated rows to the top of the creation script.  There are many other forum and user-voice posts about SQL Source Control Static Data ordering inconsistencies and the issues it causes.  The inconsistent ordering makes for extremely difficult merge conflict resolution and it makes it difficult to identify what has actually changed when viewing diffs on the git repository.  These issues make it easy to for one developer to accidentally revert static data changes made by another developers during a merge conflict because they didn't notice that a row was moved AND changed. As part of our pre-commit hook, the creation of the clone using SQL Data Compare with the /MakeScripts switch has the additional desirable side effect of creating all static data scripts with the insert statements ordered by the primary key of the table.  Our pre-commit hook then replaces any static data creation script that was part of the original commit with the consistently ordered cloned version.  This ensures all developers have the same order applied and makes it much easier to see how static data changed over time when viewing the git repository. The change in behavior prevents us from doing this anymore unless we stick with an older version or come up with a different method.  An older version works for the short term but is not a viable solution.  It would exclude us from bug fixes, new features, and security updates. My primary goal is to generate a version of the static data creation scripts in a consistent order.  I could accomplish it by running two separate SQL Data Compare commands, one to create the schema scripts and one to copy the data.  The issue that I have with that is that it forces us to do two completely separate SQL Data Compare operations.  The inclusion of a single compare in our pre-commit hook already added a noticeable delay on every commit that involves static data.  Adding a second compare operation would double the time it takes for the pre-commit hook to complete. It would be preferable to be able to run a single compare operation.. I don't have an issue using a different command, different switches, or even a completely different method - I'm mostly interested in accomplishing the same end result.  I would even be satisfied with method that creates only the static data creation scripts.  Please let me know if you have any suggestions. / comments
Thanks for confirming that there was a change in behavior.My specific use case is cloning the working version in a pre-commit hook on the SQL Source Control repository.  Once the clone is made, the...
0 votes
Hi, Using V14.3.4.16598 or earlier, the /MakeScripts option creates a directory containing all object creation scripts including the static data in a data folder. Using version V14.4.0.16632 or later, the /MakeScripts option creates a directory containing all object creation scripts except the static data. The Data folder isn't even created. I setup a basic reproduction of the issue using a 1 table database that has 2 rows of data. I created it using SQL Source Control V7.1.29.11028, set the 1 table as a static data table, and published it to a public repository on GitHub. At a command prompt, clone the repo:cd %LOCALAPPDATA%\temp\ git clone https://github.com/rdaunce/DataTest.git With SQLDataCompare V14.4.0.16632 or later installed (I used V14.4.12.17429), run the following commands:cd "\Program Files (x86)\Red Gate\SQL Data Compare 14" SQLDataCompare.exe /scripts1:%LOCALAPPDATA%\temp\DataTest /MakeScripts:%LOCALAPPDATA%\temp\DataTestCopy14.4 /LogLevel:Verbose explorer %LOCALAPPDATA%\temp\DataTestCopy14.4 This is the output of the SQLDataCompare.exe command when I ran it:SQLDataCompare V14.4.12.17429 ====================================================================================================================== Copyright c Red Gate Software Ltd 1999-2020 SQL Data Compare: activated, edition professional, serial number: XXX-XXX-XXXXXX-XXXX Warning: Some settings are missing from the RedGateDatabaseInfo.xml file in the scripts folder 'C:\Users\rdaunce\AppData\Local\temp\DataTest': default values will be used for any omitted setting. The resulting directory only has the Tables folder with a table creation script.  There is no Data folder. [image] Uninstall the current version of SQLDataCompare. Install SQLDataCompare 14.3.4.16598 or earlier and return to the command prompt:cd "\Program Files (x86)\Red Gate\SQL Data Compare 14" SQLDataCompare.exe /scripts1:%LOCALAPPDATA%\temp\DataTest /MakeScripts:%LOCALAPPDATA%\temp\DataTestCopy14.3 /LogLevel:Verbose explorer %LOCALAPPDATA%\temp\DataTestCopy14.3 This is the output of the SQLDataCompare.exe command when I ran it.  This version includes more output. SQL Data Compare Command Line V14.3.4.16598 ====================================================================================================================== Copyright c Red Gate Software Ltd 2020 SQL Data Compare: activated, edition professional, serial number: XXX-XXX-XXXXXX-XXXX Warning: Some settings are missing from the RedGateDatabaseInfo.xml file in the scripts folder 'C:\Users\rdaunce\AppData\Local\temp\DataTest': default values will be used for any omitted setting. Creating folder of scripts 'C:\Users\rdaunce\AppData\Local\temp\DataTestCopy14.3' from the scripts folder 'C:\Users\rdaunce\AppData\Local\temp\DataTest'... Registering databases Mapping Comparing databases Generating SQL scripts Deploying databases The resulting directory has the Tables folder and the Data folder.  Both contain the expected creation scripts. [image] The behavior in the second run is what I expected when I upgraded to V14.4. I have attached the log files that were created from these commands to this post.  They have been renamed to match the SQLDataCompare version that produced them. The log files both start mostly the same with different placement of the diagnostics JSON block in each.  The end of SQLDataCompare-V14.3.4.16598.log (line # 501 to 621) does not match anything found in SQLDataCompare-V14.4.12.17429.log.  The missing section looks like the portion where the data is processed.  There are no log messages or errors to indicate a problem in SQLDataCompare-V14.4.12.17429.log, it just looks like it doesn't do that part. / comments
Hi,Using V14.3.4.16598 or earlier, the /MakeScripts option creates a directory containing all object creation scripts including the static data in a data folder. Using version V14.4.0.16632 or late...
0 votes
CLI behavior change with /MakeScripts switch in 14.4
I'm using the Windows version of sqldatacompare.exe in a git pre-commit git hook script. An example of the command that it uses is:SQLDataCompare.exe /scripts1:d:\git\repo /MakeScripts:C:\temp\scri...
2 followers 5 comments 0 votes