In SSMS I'm connected to an Intersystems Cache database using ODBC driver and linked server When I fetch data using a SQL query like
SELECT Text FROM OPENQUERY([ODBC_CACHE_DB],'SELECT TOP 100 Text FROM cls.Actions')
IN SSMS it gives results but it gives ? for arabic characters like
"18:29:00 [Mohamad] ????? ??? ?? ??? ??? ?????? ????? ? 18:30:30 [Customer] Hi Sirius is jai"
how could get arabic texts ?
note: I can read and write arabic text with using nvarchar data type
Had a similar issue. My setup was a linked server setup between MSSQL 2012 cluster and Intersystems Cache 2009.x using MS OLE ODBC provider.
My observations below:
Convert/Cast on the column with nvarchar datatype did not work -- as in it shows the ???? (This is on SSMS)
When using 3rd Party DB management tools such as Database.net and WinSQL, I was able to see the correct characters.
Playing around with the ODBC driver's Unicode SQL Types function only intermittently helped show the correct characters.
The solution:
Enable Unicode SQL Types function on the ODBC driver
Make changes to the test sql query that is being executed on the Intersystems Cache db. If you keep executing the same query, the output is cached for sometime (not sure how long exactly).
In my case, the sql server cluster was not under my control and took a few days to play around with the different variations.
Related
I've migrated a database formerly in Access to SQL Server and am now rebuilding my Access front end to work with that SQL Server back end using a DSN-less link. I'm running into issues with new data entry in my time field. The error I get is ODBC--update on a linked table...failed. [Microsoft][ODBC Driver 17 for SQL Server]Invalid character value for cast specification (#0). I'm assuming this has to do with the way Access converts the data into short text from SQL Server, where it is a time(0) data type.
My question is what is the best way to handle "time" data to work in both Access and SQL Server? Ideally users would enter data in Access simply as something like "0130" where this means "1 hour and 30 minutes" (we never record seconds). And ideally the data in SQL Server would be formatted in some sort of time or datetime/datetime2 format.
I'm in a position to modify the formatting or code of the Access front end or the SQL Server back end (or both)--what's the cleanest way to go about this?
The best way is to user data type DateTime in SQL Server. Any ODBC driver will read and write that from Access as native DateTime of VBA.
If you must use DateTime2 in SQL Server, you must install and use one of the never ODBC drivers, not the "SQL Server" ODBC driver that comes with Windows as it cannot read the microsecond resolution of DateTime2.
You should never use the other date/time data types of SQL Server: Time and Short Date
I have about had it with SQL Server 2012 64 bit!
I am creating a SSIS package with a SQL query to Oracle and trying to put the file into a flat file. I am using the Oracle OLEDB source and a Flat File Destination for the output. Everything works fine locally, but when put on the server and run through SQL Agent I keep getting the Unicode to Non-unicode errors!
The latest drivers are on the server and the 11g client is on my development machine. The types shown in each step show as DT-STR.
I have the exact same source writing to an OLEDB destination just fine. I don't want to have to write these to a table and then pull them back out just to get this to work. Any solutions? And please, no "just add this" responses.
I have tried a data conversion, but get same result. Please supply DETAILED answers as in go here and change this to this. Pictures never hurt. Thanks
Short answer is that you need to convert codepages, not datatypes.
Long answer follows:
Step 0: If you're not already using it, I highly recommend that you switch to using the Attunity Connectors instead of stock Oracle OLEDB connector. You can download it for SQL2012 from Microsoft at: https://www.microsoft.com/en-us/download/details.aspx?id=29283
Step 1: Using the Attunity Oracle Source, you can specify a SQL Command as the data access mode, instead of just pointing at a table.
Step 2: You need to determine the exact code page the Oracle server is using, and the exact code page your SQL server is using. For Oracle servers using the UTF-8 character set, this is most likely AL32UTF8 and for a Windows Server using the default ANSI-1252 char set, the code page is WE8MSWIN1252.
Step 3: Write your plsql query and CONVERT the codepage of all the columns on the Oracle side. Make sure you use double quotes around the Oracle column names. It should look something like this:
SELECT
CONVERT("Data Source Code",'AL32UTF8','WE8MSWIN1252') AS DataSourceCode
,CONVERT("Order#",'AL32UTF8','WE8MSWIN1252') AS OrderNumber
,CONVERT("Invoice#",'AL32UTF8','WE8MSWIN1252') AS InvoiceNumber
,CONVERT("Item#",'AL32UTF8','WE8MSWIN1252') AS ItemNumber
,CONVERT("Order Line Type",'AL32UTF8','WE8MSWIN1252') AS OrderLineType
,CONVERT("Order Status",'AL32UTF8','WE8MSWIN1252') AS OrderStatus
,CONVERT("Order Date",'AL32UTF8','WE8MSWIN1252') AS OrderDate
,CONVERT("Invoice Date",'AL32UTF8','WE8MSWIN1252') AS InvoiceDate
,CONVERT("Ship To Cust#",'AL32UTF8','WE8MSWIN1252') AS ShipToCustNumber
,CONVERT("Billing Account #",'AL32UTF8','WE8MSWIN1252') AS BillingAccountNumber
,CONVERT("Sold Qty",'AL32UTF8','WE8MSWIN1252') AS SoldQty
,CONVERT("Unit Price",'AL32UTF8','WE8MSWIN1252') AS UnitPrice
,CONVERT("Sales Amount",'AL32UTF8','WE8MSWIN1252') AS SalesAmount
,CONVERT("Handling Amount",'AL32UTF8','WE8MSWIN1252') AS HandlingAmount
,CONVERT("Freight Amount",'AL32UTF8','WE8MSWIN1252') AS FreightAmount
FROM MYORACLEDB.DIGITAL_SALES_FEED
WHERE "Invoice Date" >= TO_DATE('2018/08/01', 'yyyy/mm/dd')
Step 4: Use this query text as the SQL command text in the Oracle Source configuration window.
Fun Fact: Oracle will return the column names in ALL CAPS, regardless of your AS ColumnName format.
Step 5 (optional): All columns will be returned as strings. You might want to put a Data Conversion task in your Data Flow, but if you're just dumping your data into a flatfile, you might not care about the data conversion. I have decimal/numeric and dates in my data set, so I do a conversion before inserting into SQL Server.
Once again with the charset issues when talking to DB's :)
I have two enviroments running Zend Server. Bot of these communicate to a SQL Server 2000 using the mssql extension. None of them has any value given for the charset in the settings of the extension. For one it works and for the other one it returns data in the wrong encoding.
The problem became noticed when this data was beeing inserted into a MySQL database and it screamed with SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\xF6m' for column 'cust_lastname' at row 1.
I tried using SET NAMES utf8 to get the SQL Server connection to return the correct data, but it complains and says that NAMES is not a recognized SET statement. Looking around most people even recommend using this but it doesn't seem to be part of SQL Server 2000 :)
So, what should I do? How do I, WITHOUT fiddling with the SQL Server database/tables, tell it to send me the data in UTF-8 encoded format?
EDIT:
Some more info...
SQL Server uses the Finnish_Swedish_CI_AS collation
MySQL has every table in UTF-8 format and uses utf8_unicode_ci
I didn't find a good solution and ended up converting to and from utf8 in my application. If this is encapsulated within a class it doesn't riddle the code. But a way to actually tell the SQL server which encoding to use during communication would be better.
I have created a linked-server definition according to the article at :
http://www.ideaexcursion.com/2009/01/05/connecting-to-oracle-from-sql-server/
My aim is to transfer rows to tables at Oracle 11gR2.
After creating linked server, whenever I try to select a table using a query like :
SELECT *
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I get the error below :
Msg 7356, Level 16, State 1, Line 1
The OLE DB provider "OraOLEDB.Oracle" for linked server "192.168.1.188"
supplied inconsistent metadata for a column. The column "EVENT_OBJECT"
(compile-time ordinal 2) of object ""ESIPARIS"."T_ERROR_LOG"" was reported
to have a "LENGTH" of 50 at compile time and 100 at run time.
One more thing is that it duplicates field names whenever a select statment is prepared by "Sql Server Management Studio", some fields are duplicated as below :
SELECT [EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[EVENT_ID]
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I would be very happy to hear from you about any ideas, thank you for your concern,
Best Regards,
Kayhan YÜKSEL
There are a number of scenarios which might throw this error:
your distributed query in SQL Server references a view with an underlying table in Oracle with a primary key column created in a certain way, Find out more
there's a bug when the querying a view with numeric columns. Find out more
it may be a problem with driver incompatibility, such as using the MS OleDB driver instead of the one Oracle provides.
If it isn't the driver one possible workaround is to use OPENQUERY. Otherwise. this support note contains general information on troubleshooting linked server and Oracle.
(This problem is a fairly generic one, so it turned out that the actual resolution was none of the things I suggested. I'm incorporating #kayhanyüksel's solution in the body of this response for the sake of completeness.)
Solved it with changes at listener and tnsnames. We are now able to connect from SQL Server to Oracle 11gR2 (running on 64 bit Red Hat Enterprise Linux 5.4 ) and vice versa. Documents followed are
- Making a Connection from Oracle to SQL Server
- The Oracle Gateways documentation
I had the same problem: The column ...... was reported
to have a "LENGTH" of 50 at compile time and 100 at run time. and duplicate column names when selected.
while i was trying to run a query in MS SQL from an ORACLE 11g database
I used the follownig type of query and it worked !
DECLARE #TSQL varchar(8000)
SELECT #TSQL = 'SELECT * FROM OPENQUERY(MyLinkedServer,''SELECT * FROM TableName'')'
EXEC (#TSQL)
where MyLinkedServer is the name of the linked server and
TableName is the name of the table.
here you have the link to the article that helped me: http://support.microsoft.com/kb/314520
Old thread but it may be useful to someone.
When I recently encountered this error, using as provider the MS OleDB driver instead of the Oracle OleDB provider solved the problem.
I have the same issue with 11g client but it was disappeared with client version 12 which works for me is using OPENQUERY and to_char with the field that makes problem.
I confirm that SQL management studio (no matter what version) gives many duplicated field. The only installing of last driver version we can have consistent queries. I hope it can be useful for you!
I am upscaling an access 2003 database to SQL Server Express 2008. The tables appear to be created ok and the data looks ok.
I have an MFC application that connects to this database. It worked fine connecting to access, but when I connect to SQL Server I am getting the following error on a select statement.
DBMS: Microsoft SQL Server
Version: 10.50.1600
ODBC Driver Manager Version: 03.80.0000
Warning: ODBC Success With Info on field 0.
String data, right truncation
State:01004,Native:0,Origin:[Microsoft][ODBC SQL Server Driver]
The data that is returned should be 8 characters but is only 7 with the right most character truncated.
The access front end can read the data from SQL Server correctly.
The field in the SQL Server table is defined as nvarchar with a length of 8.
The code to read the field looks something like
CDatabase Database;
CString sSerialNumber = "00000000";
CString SqlString;
CString sDsn = "Driver={SQL Server};Server=server\\db;Database=Boards;Uid=uid;Pwd=pwd;Trusted_Connection=False";
Database.Open(NULL,false,false,sDsn);
CRecordset recset( &Database );
SqlString.Format("Select SerialNumber from boards where MACAddress = '%s'",mac);
recset.Open(CRecordset::forwardOnly,SqlString,CRecordset::readOnly);
recset.GetFieldValue("SerialNumber",sSerialNumber);
After this, sSerialNumber should be 12345678 but its 1234567
Thanks for the help
I'd agree that this is driver related. The {SQL Server} driver was introduced for use with SQL 2000. {SQL Native Client} came along with 2005. Ideally, for your 2008 database, you should use the newest {SQL Server Native Client 10.0}. The newer drivers are backward compatible with older versions of SQL Server.
Changing my driver from
"Driver={SQL Server};"
to
Driver={SQL Native Client};
has made the problem go away, but I'm not sure what was going on. I'm going to keep looking into it
From a bit of Googling, I've learned that apparently, at times, particularly when "Use Regional Settings" is checked in the MS SQL Server ODBC driver DSN setup dialog, ODBC will treat a string made up of all digits, as a number, and return it like "12345678.00" which doesn't fit into the space you've given it. The solution is to turn that setting off, either in the dialog box, or, more permanently, in the connection string:
CString sDsn = "Driver={SQL Server};Server=server\\db;Database=Boards;"
+"Uid=uid;Pwd=pwd;Trusted_Connection=False;Regional=No;"
If you absolutely have to dig to the bottom of this, make a minimal stored procedure that will "select" local var defined as varchar(17) - any size more than 2x your original size will do. Now call the sproc instead of dynamic SQL and see what comes back. Then you can repeat it with exactly the same size (nvarchar(8)). Your little sproc serves as easy data adapter and to stabilize typing if old driver tends to get confused - much easier than fiddling with table definition.
Also, check if there's any param/property on inreface/connection classes to specify character encoding and make sure that it's unicode (utf-16). I assume that your code gets compiled for unicode. If not, you need to make decision about that first (N in Nvarchar means unicode, otherwise it would be just varchar). You definitely need character encoding matched at both sides or you will have other spurious errors.