A colleague tells me that there is no way to bulk insert UTF-8 encoded data into a Microsoft SQL server 2008.
Can this be true? Is there any stuff you would recommend him to read or look at?
UTF-8 isn't a part of SQL Server's Unicode strategy (unfortunately). However, UTF-8 is well supported in .NET. If you are willing to write .NET code, you could use the System.Data.SqlClient.SqlBulkCopy class in conjunction with a System.IO.StreamReader and/or `System.Text.Encoding.UTF8'.
Another option is Integration Services. For file connections, you can choose code page 65001 (UTF-8).
It is true. The documentation for BULK INSERT says 'SQL Server [2008] does not support code page 65001 (UTF-8 encoding)'.
There was once a Microsoft Connect Page about this issue, but Connect is now gone.
Related
I have a geometry layer stored in SQL Server 2016. I've downloaded Geoserver's plug-in from the web site.
Geoserver Documentation clearly states that Geoserver doesn't support SQL Server on default. I've followed the instructions and I was able to see Microsoft SQL Server as a data source.
When I try to connect to my SQL Server the interface is just different from documentation. It doesn't even ask any user credentials and the name of the data source is also different from documentation.
The interface;
My question is Geoserver doesn't really support SQL Server 2016 or am I doing something wrong ?
Thanks
H.
A JNDI connection should already be configured with the connection parameters in the web servlet container (tomcat, jetty, etc). Therefore geoserver doesn't need to ask again. Maybe what you need is the JDBC connection next to it in the list.
I'm not sure if anyone has tested it with sqlserver 2016 but feel free to update the documentation if you find it does (or if it didn't work too).
We are installing a new application, the pre-requisite of which says that your database must be configured to use the UTF-8 character set.
We are currently using SQL Server 2016, enterprise edition.
Our database team mentioned to us that SQL Server doesn't support UTF-8 and have suggested to use nChar and nVarchar datatype for UTF-8 character set support.
I am not a database expert unfortunately. Could someone please help understand what exactly could be done here?
I am trying to create a linked server from SQL Server 2008 R2 to an SAP IQ database, which has the UTF-8 Charset.
I am unable to get the correct characterset viewable on queries using this linked server.
I have tried everything, using native OLE DB provider of SAP IQ, using ODBC connectivity, playing with different connection strings, but my major concern is that it's impossible because SQL Server does not support UTF-8.
Correct characters when viewing in Interactive SQL:
Messed up characters in SQL Management Studio:
Any thoughts?
Finally solved it, after a few hours of debugging. :)
You have to use an ODBC connection, with the CharSet parameter set to 'windows-1252'. Then it works perfectly.
I have a general question about using ADO together with SQL-server 2008express (Microsoft).
When sending a SQL command to the server from let's say an EXCEL application, is there away (eg using the management studio) to see EXACTLY what the command the server received looked like? I know how it looked like in the VBA debugger, but sometimes strange things like commas turning into dots happen. It wold be much easier to track such bugs down this way.... Can i create some kind of log file on the server where I see everything that was tried ?
Regards Lumpi
If you have a full edition of SQL Server (even Developer edition will do), use SQL Profiler to capture the queries. If you don't have access to the Microsoft tool there is an open source profiler available for express.
I am releasing a database build to SQL Server 2000 via a batch file using isql. The batch file is used so multiple files are released consistently to different SQL Servers (development, test, live).
The SQL Server uses ANSI code page 1252 (from sp_helpsort) but isql is an OEM client using code page 437. This means that all extended characters (with ASCII code > 128) are converted when the scripts are run, leading to inconsistent results when characters like “£” are included in the script. Differences are explained in this Microsoft knowledgebase article.
Possible solutions are: -
Save the script using Unicode and
use osql.
Turn off the AutoAnsiToOem setting using the SQL Server Client Network Utility (that writes a registry key).
Both these options rely on various people doing things consistently. All have to select the same code page option when saving a file OR all people performing the builds have to have the same option set for AutoAnsiToOem.
Is there a way to force the use of a code page either in the SQL script OR in the batch file that calls it, so that the build is always released consistently, regardless of how the file is saved or the various settings of whoever performs the release?
isql is obsolete. It isn't included in SQL Server 2005 or later, because it uses the DB-Library connections, which are also obsolete. For the reasons why, and the effects this has, see Connecting Early Version Clients to SQL Server 2000.
osql uses ODBC connections to connect to SQL Server. For completeness, this has been supplemented by sqlcmd in SQL Server 2005, which uses OLE DB with the SQL Native Client provider.
Further to the accepted answer, I have tested using sqlcmd against a SQL Server 2000 database and it works. You obviously have to run sqlcmd from a machine with the SQL Server 2005 client tools installed.