I am migrating data from a Oracle on VMS that accesses data on SQL Server using heterogeneous services (over ODBC) to Oracle on AIX accessing the SQL Server via Oracle Gateways (dg4msql). The Oracle VMS database used the WE8ISO8859P1 character set. The AIX database uses WE8MSWIN1252. The SQL Server database uses "Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data" according to sp_helpsort. The SQL Server databases uses nchar/nvarchar or all string columns.
In Application Express, extra characters are appearing in some cases, for example 123 shows up as %001%002%003. In sqlplus, things look ok but if I use Oracle functions like initcap, I see what appear as spaces between each letter of a string when I query the sql server database (using a database link). This did not occur under the old configuration.
I'm assuming the issue is that an nchar has extra bytes in it and the character set in Oracle can't convert it. It appears that the ODBC solution didn't support nchars so must have just cast them back to char and they showed up ok. I only need to view the sql server data so I'm open to any solution such as casting, but I haven't found anything that works.
Any ideas on how to deal with this? Should I be using a different character set in Oracle and if so, does that apply to all schemas since I only care about one of them.
Update: I think I can simplify this question. SQL Server table uses nchar. select dump(column) from table returns Typ=1 Len=6: 0,67,0,79,0,88 when the value is 'COX' whether I select from a remote link to sql server, cast the literal 'COX' to an nvarchar, or copy into an Oracle table as an nvarchar. But when I select the column itself it appears with extra spaces only when selecting from the remote sql server link. I can't understand why dump would return the same thing but not using dump would show different values. Any help is appreciated.
There is an incompatibility between Oracle Gateways and nchar on that particular version of SQL Server. The solution was to create views on the SQL Server side casting the nchars to varchars. Then I could select from the views via gateways and it handled the character sets correctly.
You might be interested in the Oracle NLS Lang FAQ
Related
I have moved MS Access 2010 Data to SQL using their tools, and now filtering by Unicode is not working in Access linked tables. I see the linked table column in SQL is "nvarchar" but in Access there is "Unicode compression" set to "No" and I can't change it.
It is my understanding that the "Unicode compression" setting only affects native Access (ACE/Jet) tables and has no effect on ODBC linked tables. Instead, what you likely need to do is change the "Collation" setting of the SQL Server database itself by using SQL Server Management Studio:
For example, with the above SQL Server collation setting ("SQL_Latin1_General_CP1_CI_AS") I cannot filter on Greek characters (e.g., 'γιορτή') from Access, but if I change the collation of the SQL Server database to "Greek_CI_AS" then that same Access filter will work.
Edit re: comments
While this solution will work for single-byte code pages that are natively supported by SQL Server (e.g., Greek, which would correspond to Windows-1253), it won't work for languages that lack those code pages and must be represented either by
a code page that is not supported by SQL Server, or
Unicode.
ODBC linked tables in Access apparently do not fully support Unicode, passing search strings to SQL Server as 'text', not as N'text', so SQL Server feels compelled to interpret any such text according to the selected single-byte code page (via the "Collation") setting.
I am new to MS SQL and I am trying to do something that seems simple but is driving me crazy.
I want to write a query to pull data from two databases. Each database is on a different instance on the same DEV machine. (one is MS SQL 2008 and the other MS SQL 2005). I am using the Microsoft SQL Server Management Studio (MSSMS).
I have the basics figured out. I know the format of the query and what I need to do. My big problem is figuring out what the NAME of each server is?
SELECT LastName
FROM [servername1].CHA2.dbo.Customer
UNION
SELECT LastName
FROM [servername2].OBXKites.dbo.Contact
ORDER BY LastName
I used the server name that I connect to MSSMS (DLPT\HENRY) with and what is also returned by ##SERVERNAME
SELECT ##SERVERNAME returns DLPT\HENRY
I tried
DLPT\HENRY.CHA2.dbo.Customer
did not work
I tried it without the DLPT HENRY.CHA2.dbo.Customer
did not work
I need to future out what the NAME of the server is to use in the query.
[DLPT\HENRY].CHA2.dbo.Customer
The namo contains a backslash which is normally illegal in an identifier. You surround illegal names with brackets.
Note that you surround just the server name. In other words, it is [DLPT\HENRY].CHA2.dbo.Customer, not [DLPT\HENRY.CHA2.dbo.Customer].
You have to configure Linked servers. Then only different instances of SQL Server are able to communicate with each other.
Unfortunately you can't access tables in databases in separate SQL Server instances by default. You have a couple of options here - neither are simple and might require help from a DBA:
1) Use linked servers like this:
http://technet.microsoft.com/en-us/library/ff772782(v=sql.110).aspx
Then you will be able to refer to the second table in the format INSTANCENAME.DatabaseName.SchemaName.TableName
2) Use replication to get the table from the second database into the first database. Then the contents of the second table will be synched to the first database in more or less real time
Read about SQL Replication here
I'm running into a problem when accessing a SQL Server table from an Oracle setup via ODBC.
I can access 90% of the tables absolutely fine, but there's a few tables that have a name that's longer than 30 characters. Whenever I try to interact with the table (describes, selects, etc) Oracle throws an "identifier too long" error and gives up.
Is there a way to coax Oracle into playing nice with the SQL Server tables?
Assuming that we are talking about an Oracle database that has a database link created to a SQL Server database via Heterogeneous Services, you would need to write code using the DBMS_HS_PASSTHROUGH package to interact with the tables in question. You'd also need to use this package if you have tables where there are column names that are not valid Oracle identifiers.
I am using Access 2003 as a front end UI for a SQL Server 2008 database. In looking at my SQL Server database design I am wondering if nvarchar was the right choice to use over varchar. I chose nvarchar because I thought it would be useful in case any characters represented by unicode needed to be entered. However, I didn't think about any possible issues with Access 2003 using the uni-code datatype. Are there any issues with Access 2003 working with unicode datatypes within SQL Server (i.e. nvarchar)? Thank you.
You can go ahead and use nvarchar, if that's the correct datatype for the job. Access supports Unicode data, both with it's own tables and with external (linked) tables and direct queries.
I have a backup of an SQL Server DB in .bak format which I've successfully managed to restore to a local instance of SQL Server Express. I now want to export both the structure and data in a format that MySQL will accept. The tools that I use for MySQL management typically allow me to import/export .sql files, but unfortunately Microsoft didn't see fit to make my life this easy!
I can't believe I'm the first to run into this, but Google hasn't been a great deal of help. Has anybody managed this before?
There will be 2 issues:
1) Datatypes. There isn't always a direct analog between an MS SQL type and a MySQL type. For example, MySQL handles timestamps very differently and has the cut-off for when you need to switch between varchar(n) and varchar(max)/text at a different value of n. There are also some small differences in the numeric types.
2) Query syntax. There are a few differences in the query syntax that, again, don't always have a 1:1 analog replacement. The one that comes to the top of my mind is SELECT TOP N * FROM T in MS SQL becomes SELECT * FROM T LIMIT N in MySQL (MySQL makes paging loads easier).