Comments
Sort by recent activity
So the product is supposed to create those folders and clean them up? Is there a default location defined in the code if an RGTEMP doesn't exist? I do not have an env variable defined for RGTEMP (Windows 2008r2 Standard).
Is there any other place from which the software would pick up such a path? I keep wondering if there's any relationship to the fact that the trees contain SSC control files.
Thank you for your help. I know how frustrating it can be when an issue cannot be reproduced easily. / comments
So the product is supposed to create those folders and clean them up? Is there a default location defined in the code if an RGTEMP doesn't exist? I do not have an env variable defined for RGTEMP (W...
I tried the same data comparison, but using exported folders as per your suggestions. I verified that the tree truly was an export and did not contain any subversion control files. The older version's tree still exhibits the originally reported behavior. [image]
As I metioned in the original post, this does not seem to affect the results. It adds some small files to the tree, which produce warnings in the comparison output. The more important artifacts (SQL scripts, CSV summaries, SDC files) appear to be correct.
With regard to the new, numerically-named folder, does that behavior match up with expected product behavior? If it does, it would seem that the issue is cleaning up temporary files. / comments
I tried the same data comparison, but using exported folders as per your suggestions. I verified that the tree truly was an export and did not contain any subversion control files. The older versio...
Any update on this? I am also experiencing this behavior in SQL Data Compare 10.2.0.315. Per the "check for updates" feature, that is the latest version.
What is a little more bizarre is that when I use the Open Project dialog box, it displays both SCP and SDC files. All of the saved projects compare 2 SVN paths, so the "Data Source" columns in the dialog box are empty. I do observe that the SVN paths are in the SDC file.
Using SQL Data Compare with the 2 SVN paths works correctly. It's just that saving a SDC file is worthless for this comparison since I have to re-select all 4 SVN paths anyway (db + migration scripts for each).
Those SCP files work just fine in SQL Compare (10.1.0.102). In fact, the SDC file also opens in SQL (schema) Compare, but I'm not sure why. / comments
Any update on this? I am also experiencing this behavior in SQL Data Compare 10.2.0.315. Per the "check for updates" feature, that is the latest version.
What is a little more bizarre is that when ...
We haven't seen any ill effects. My coworker spotted it when he noticed that the XML file wasn't part of an SVN update command.
This is our perspective on it:
We have to treat SVN as the absolute truth. By having 2 "lists" (the data script files and the XML config) that don't agree, we don't have truth.
It appears that the product is using the script folder over the XML file. If the product is changed regarding how it uses those files, we don't know how it will resolve the discrepancies. Will the XML file be updated to match the data scripts folder (a.k.a. the current location of the truth)? Will there be a dialog box that will let us choose what to do with each one?
I'm not saying this as an issue that needs to be a top priority, but we'd really urge you to put a lot of thought into how you handle changes to this part of your application. It's probably more concerning since it seems likely that there will be more changes coming as to how the data comparison will work with SSC. / comments
We haven't seen any ill effects. My coworker spotted it when he noticed that the XML file wasn't part of an SVN update command.
This is our perspective on it:
We have to treat SVN as the absolute t...
Hi James,
We actually encountered this exact issue today in 2.2.1.23. / comments
Hi James,
We actually encountered this exact issue today in 2.2.1.23.