I've been using Narayana Vyas Kondreddi's excellent stored procedure sp_generate_inserts http://vyaskn.tripod.com/code/generate_inserts.txt in a SQL Server 2005 database.
But after moving to SQL Server 2008 I get weird results where a long whitespace is inserted after UNIQUEIDENTIFIER values:
INSERT INTO [BannerGroups]([Id], [DescriptionText], [Width], [Height])
VALUES('BFCD0173-9432-47D1-84DF-8AB3FB40BF76 ', 'Example', 145, NULL)
Anyone know how to fix this?
Appears to be this section, just over half way down:
WHEN #Data_Type IN ('uniqueidentifier')
THEN
'COALESCE('''''''' + REPLACE(CONVERT(char(255),RTRIM(' + #Column_Name + ')),'''''''','''''''''''')+'''''''',''NULL'')'
See it's converting to a CHAR(255) which means the value is being padded out to 255 characters. Change that to VARCHAR instead and it should be fine as that will not pad the values out with spaces.
Since SQL Server 2008 we can generate the INSERT scripts via Generate Script utility itself.
For more detailed answer check out - What is the best way to auto-generate INSERT statements for a SQL Server table?
Related
Any idea why the two hashing functions in SQL Server and Oracle yield different results when hashing the non-breaking space character?
Oracle select standard_hash('a ', 'MD5') from dual; results in 25EF28EB5A5BE667C6222418E9E27E8E and doesn't match SQL select HASHBYTES ('MD5','a '); results in CE8F03020C81133B3A082F8051EB9FF6. Note the space after the input 'a' is a non-breaking space character.
Is there any good source that can lay out the differences?
This appears to be a character set or "collation" issue, where Oracle is in UTF-8 and SQL Server is in Latin 1252. My solution was to CONVERT the value to Windows Latin-1252 in Oracle before calculating the hash: select STANDARD_HASH(CONVERT('a ','WE8MSWIN1252'), 'MD5') from dual.
To find my collation/character set I did SELECT collation_name FROM sys.databases WHERE name = 'MY_DB_NAME'; in SQL Server and select * from nls_database_parameters where parameter='NLS_CHARACTERSET'; in Oracle.
First of all you need to establish which one is actually yielding "different" results:
Using your favourite search engine to find online hash generators and testing results.
External Resources
https://passwordsgenerator.net/md5-hash-generator/ - 99020CB24BD13238D907C65CC2B57C03
https://www.md5hashgenerator.com/ - 99020cb24bd13238d907c65cc2b57c03
https://www.miraclesalad.com/webtools/md5.php - 99020cb24bd13238d907c65cc2b57c03
SQL Server
select HASHBYTES ('MD5', 'a ')
SQL Server 2014 SP3 (12.0.6024.0) - 0x99020CB24BD13238D907C65CC2B57C03
SQL Server 2019 (15.0.2080.9) - 0x99020CB24BD13238D907C65CC2B57C03
Oracle (using https://dbfiddle.uk/)
select standard_hash('a ', 'MD5') from dual;
Oracle 21c - 0x99020CB24BD13238D907C65CC2B57C03
Oracle 18c - 0x99020CB24BD13238D907C65CC2B57C03
Oracle 11gR2 - "ORA-00904: "STANDARD_HASH": invalid identifier"
Conclusion
You can see that your Oracle produced answer differs even from other Oracle answers. What version of Oracle are you running? What other options are set, such as collation etc.?
I am converting Access query to SQL Server.
I want to convert below lines to SQL
1. Format (210.6, "Standard")
2. Format (210.6, "#,##0.00")
How do i convert it to SQL query.
I have tried with below, but still not able to find the solution.
For the first query, i found below solution, which is correct
1. CONVERT(varchar, CAST(tSRO.OutputF11 AS money), 1)
Now, for second query, i do not know what i have to do.
From SQL Server 2012+ you can use FORMAT:
SELECT FORMAT(210.6, '#,##0.00') -- 210.60
SELECT FORMAT(1210.6, '#,##0.00') -- 1,210.60
LiveDemo
SQL Server before 2012:
SELECT REPLACE(CONVERT(VARCHAR,CONVERT(MONEY, 1210.6),1),'.00','') -- 1,210.60
LiveDemo2
Warning:
This operation is pure for presentation layer and should be done in application.
I am running a SQL Server 2008 R2 and I have a database containing multilingual words.
For Cyrillic words I only see '???????'
The data type is nvarchar(255), the collection is SQL_Latin1_General_CP1_CI_AS (which was my default)
I have no idea what else can I do, any idea??
When you add data to the nvarchar column, use the prefix N
Insert into table(nvarchar_col)
select N'your Cyrillic words'
I have a SQL Server 2008 R2 table with nvarchar(4000) field.
Data that stores this table look like
'696D616765206D61726B65643A5472'
or
'303131' ("011").
I see that each char is encoding to hex.
How can I read those data from table? I don't want write decoding function, I mean that simpler way exists.
P.S. Sorry for my English.
SQL Server 2008 actually has a built-in hex-encoding and decoding feature!
Sample (note the third parameter with value "1" when converting your string to VarBinary):
DECLARE #ProblemString VarChar(4000) = '54657374'
SELECT Convert(VarChar, Convert(VarBinary, '0x' + #ProblemString, 1))
Ref: http://blogs.msdn.com/b/sqltips/archive/2008/07/02/converting-from-hex-string-to-varbinary-and-vice-versa.aspx
The advantage of this approach is that you don't need the "Exec" call, which you generally try to avoid, for fear of injection among other things. The disadvantage is that it only works in SQL Server 2008 and later.
You will need a decoding function I think, the simplest:
declare #fld nvarchar(4000) = '696D616765206D61726B65643A5472'
exec('SELECT CONVERT(varchar(max),0x' + #fld + ')')
---------------
image marked:Tr
I am using SQL Server 2008 express edition and its collation settings are set to default.I wish to store special characeters like á ,â ,ã ,å ,ā ,ă ,ą ,ǻ in my database but it converts them into normal characters like 'a'. How can I stop SQL Server from doing so?
Make sure that your columns are using the type nvarchar(...), rather than varchar(...). The former is Unicode, the latter is ASCII.
Also, make sure that your database default collation is set to Accent Sensitive, and that your columns are stored that way. You may also want to check your instance default collation, as that affects the default collation for your system databases, particularly tempdb.
Rahul, here is a very simple query that runs perfectly on SQL 2005 and 2008:
Query
DECLARE #t1 TABLE (
Col1 nvarchar(30)
)
INSERT INTO #t1 VALUES (N'á ,â ,ã ,å ,ā ,ă ,ą ,ǻ')
SELECT * FROM #t1
Result
Col1
------------------------------
á ,â ,ã ,å ,ā ,ă ,ą ,ǻ
There is nothing special here. No collation change from default, just a simple NVARCHAR column.
You said you are "just running direct queries in the database". Can you try this query and see if you get the same results?