Activity overview
Latest activity by kipb7
Thanks, it is faster. My windows profile files are on a shared file system, which ordinarily is super zippy so I don't think that is a cause for delay, unless Red Gate opens/closes/opens/closes a lot or something.
First time starting SSMS after update:
12 Feb 2015 18:41:08,972 [1] INFO RedGate.SQLPrompt.CommonVS.BaseConnect.1 - DoUiSetup() - recreating commands and cleaning up obsolete commands
12 Feb 2015 18:41:51,930 [1] INFO RedGate.SQLPrompt.CommonVS.BaseConnect.1 - DoUiSetup() complete.
(about 43s)
Second time 4s, Third time 3s.
Thanks! / comments
Thanks, it is faster. My windows profile files are on a shared file system, which ordinarily is super zippy so I don't think that is a cause for delay, unless Red Gate opens/closes/opens/closes a ...
Also slow to change options - such as Options > Format, change something, click OK, wait 60 seconds for window to close. No error.
Log file has (seemingly corresponding to the two times I just did this):
07 Feb 2015 03:54:32,555 [1] INFO RedGate.SQLPrompt.CommonVS.BaseConnect.1 - Creating menus for SQL Prompt edition Full
07 Feb 2015 03:57:11,145 [1] INFO RedGate.SQLPrompt.CommonVS.BaseConnect.1 - Creating menus for SQL Prompt edition Full
It doesn't list duration, but this could be a clue of what it was doing. Perhaps it can't save the "menus" in my file system or profile.
I found a report for a similar issue, answered Nov 22, 2011 by Anuradha D, call reference F0051414, who said "problems setting key bindings on startup...possible cause is a corrupt configuration file."
At his request, I deleted the files and the speed improved. These same files do not seem to exist now. / comments
Also slow to change options - such as Options > Format, change something, click OK, wait 60 seconds for window to close. No error.
Log file has (seemingly corresponding to the two times I just did...
Slow startup under SSMS
Just did an update from a 2-year old version, to SQL Prompt 6.4.1.142. Happy with new features, thanks!
But...
Starting SQL Server Management Studio (SQL 2008 R2) takes a minute to start up. I'm ...
ronnymr wrote,
"I am comparing 1 column of data (varchar 255) and getting unexpected results. Although many rows match, there are instances where rows do not match, yet the data appears identical. I have tried querying both database tables with the suspect data and I get matches in both. "
If your varchar has a trailing space in one version and not in the other, SQL Data Compare will say they are different, but they will look alike.
You can also do the SELECT * FROM xxx WHERE vchar='hello'
and get the row from each one -- even though one of them has vchar='hello ' (with trailing space)
even doing len(vchar) will give the space-trimmed length, so you won't see the difference.
One way to see the difference is to do
select vchar+'x' [vcharx] from xxx where vchar='hello' / comments
ronnymr wrote,
"I am comparing 1 column of data (varchar 255) and getting unexpected results. Although many rows match, there are instances where rows do not match, yet the data appears identical...
Chris wrote, "Issues such as this do occasionally come up so your idea of a 'sloppy compare' option [for floats] is a good one and one that we will consider adding in future versions."
I know this is an old thread, but if anyone is still considering this, I'd encourage you to FIRST implement accurate synchronization of floats, so there is less need for sloppy compare.
An example is the float 1.0646328852929699e-2 which SQL Data Compare does not express with enough decimal places to make a valid copy. / comments
Chris wrote, "Issues such as this do occasionally come up so your idea of a 'sloppy compare' option [for floats] is a good one and one that we will consider adding in future versions."
I know this ...
DECLARE @fa FLOAT = 1.0646328852929699e-2
DECLARE @fb FLOAT = 1.0646328852929700e-2
SELECT 'fa'[number], @fa [f], CONVERT(DECIMAL(25,20), @fa) [decimal] UNION
SELECT 'fb'[number], @fb [f], CONVERT(DECIMAL(25,20), @fb) [decimal] UNION
SELECT 'diff', (@fa-@fb), CONVERT(DECIMAL(25,20), @fa-@fb)
--Output:
number f decimal
fa 0.0106463288529297 0.01064632885292970000
fb 0.0106463288529297 0.01064632885292970000
diff -1.73472347597681E-18 0.00000000000000000000
These two floats look identical if you use SQL Server 2008 R2's conversion to decimal, but they are not identical.
While a float might approximate a particular real number, it is an exact binary value representing an exact number.
It is reasonable to expect operations on it to give the closest answer and not resort to "but it's approximate!"
Here the question is whether the decimal representation is the best available for reproducing that float when doing synchronization.
SQL Server fails at this task.
SQL Data Compare does not have to fail if it would use 17 significant decimal digits or transfer numbers in a different form.
This problem is in addition to the earlier reported need for SQL Data Compare to specify that the data value is float by using E0 on the end, since SQL otherwise assumes it is decimal and incorrectly converts some numbers to float, such as 0.85195833333333271 versus 0.85195833333333271e0 which are not equal numbers to SQL. / comments
DECLARE @fa FLOAT = 1.0646328852929699e-2
DECLARE @fb FLOAT = 1.0646328852929700e-2
SELECT 'fa'[number], @fa [f], CONVERT(DECIMAL(25,20), @fa) [decimal] UNI...
As we've seen earlier, many floats are not correctly synchronized by SQL Data Compare.
Previously, it was suggested that appending e0 onto the end of a float would make SQL process it as a float instead of as a decimal. Here is a case where that does not work, and it may be an error in how Red Gate generates the decimal value for a float.
create table dbo.FloatTest (PK INT PRIMARY key, Fraction FLOAT)
insert into dbo.FloatTest (PK, Fraction) Values (1, 0.07689223240363979e0)
DECLARE @F1 FLOAT
SELECT @F1 = Fraction FROM dbo.FloatTest
PRINT CONVERT(DECIMAL(17,17),@f1)
--prints 0.07689223240363979 -- looks good, right?
Also create this table on another database - but without the INSERT.
Now use SQL Data Compare and see what value is generated:
INSERT INTO [dbo].[FloatTest] ([PK], [Fraction]) VALUES (1, 0.0768922324036398)
--This rounds to 16 places, it seems, or 15 significant figures.
As in the original report, this is the incorrect binary value for the float. Here's the new part: adding on e0 is ALSO INCORRECT:
INSERT INTO [dbo].[FloatTest] ([PK], [Fraction]) VALUES (1, 0.0768922324036398e0)
So, would it be possible to get Red Gate Data Compare's Synchronize to synchronize floats correctly? We have been manually appending e0 onto floats for some months now when synchronizing. Now we see this is not enough. / comments
As we've seen earlier, many floats are not correctly synchronized by SQL Data Compare.
Previously, it was suggested that appending e0 onto the end of a float would make SQL process it as a float in...
I still get this error in SQL Data Compare 9.0.0.117
In the past, I've just created a new project. It is tiresome to re-discover the various settings I had set for comparing certain database pairs.
Perhaps the product could give a more descriptive message, such as which table or column, or what we can do about it? / comments
I still get this error in SQL Data Compare 9.0.0.117
In the past, I've just created a new project. It is tiresome to re-discover the various settings I had set for comparing certain database pairs...
You might enjoy the Microsoft response on this; It perhaps indicates that Red Gate should represent floats with E notation, not default decimal. Here is my report to Microsoft:
--Some floats parse inconsistently:
DECLARE @A FLOAT, @B FLOAT
SET @A = 0.8519583333333327
SET @B = 0.85195833333333271
IF @A>@B PRINT 'Greater' --prints
PRINT @A-@B --positive (expect 0 or negative)
One can work around this either by appending 'E0' onto the end of the float or by using CONVERT(float,'0.85195833333333271'). The numbers above are equal using either. These also helped with about 10,000 other such cases. Here is the reply:
"The behavior you are seeing is by design. When you specify a floating point value without the scientific notation, it is actually considered a decimal value not float. And you are then converting the decimal value to float which can result in rounding errors depending on the value.
"In your case, the value for @A is represented by decimal(16, 16) and @B is represented by decimal(17, 17). As you discovered, you
should use the scientific notation for specifying the floating point value.
"Btw, you can determine the type of a constant by doing something like below:
declare @v sql_variant = 0.8519583333333327;
select sql_variant_property(@v, 'BaseType') ,
sql_variant_property(@v,'Precision') ,
sql_variant_property(@v, 'Scale');
-- Umachandar, SQL Programmability Team" / comments
You might enjoy the Microsoft response on this; It perhaps indicates that Red Gate should represent floats with E notation, not default decimal.Here is my report to Microsoft:
--Some floats parse ...