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.
Related
I'm running a Windows application on Linux under Wine, that accesses a SQL Server using the ODBC Driver 17 for SQL Server, for Linux.
It runs fine except that I see incorrectly represented the varchars with non-Ascii characters. The nvarchar fields (unicode strings) have no problem.
Example:
select rtrim('Presentación ')
Returns: Presentación
My database has the encoding for varchars defined as iso8859-1, and Wine seems to use the cp1252 page code.
My guess is that the ODBC driver for Linux retrieves correctly the data and transforms them to UTF8, which runs fine (I can see the values correctly if I run my queries directly through isql), but when those strings are passed to my application, under Wine, they must be considered as cp1252 and that's when I see them incorrectly.
Has anyone had the same problem? what could I try?
Thank you.
I am migrating a MS Access back end data file to SQL Server. All data has successfully transferred, and it viewable in SSMS, however, if I open the linked table in the Access front end, all currency field entries that are greater than 0 are blank.
If I run a query that filters currency columns based on their value, I get the correct number of records returned, but still the fields show as blank.
This makes no sense to me, please help.
I would try linking the table using sql driver (this is a long time legacy driver). It been pre-installed on computers since windows XP.
If that does not work, then try linking using the native 11 (or later driver). These drivers are preferred, but they are not installed on each workstation and thus deployment can be a hassle.
And to prevent the need to configure each workstation? Always (but always) use a FILE dsn. This is suggested because Access will convert the connection automatic to DSN-less. This means that you not have to setup a DSN on each workstation (but you STILL require the native driver 11-17 having been installed on each workstation, and that driver will have to match what you linked with.
If EITHER of the above STILL does not display the money type columns?
Then this is a regional setting. (the regional setting of the sql server is not matching what your regional settings are on the client workstation.
So, then create a new DSN (as noted always FILE).
And during the re-link process try selecting the regional settings:
So, you should not have to change the "money" type to decimal. And doing so could introduce all kinds of issues.
So, try the above first. Both the legacy (windows built in) "sql driver", and the natve 11-17 drivers work for me WITHOUT having to select the above regional settings, but if both sql legacy and the newer native 11 (or later) drivers don't work, then try re-linking again and selecting the above option.
NOTE ALSO that you do NOT get the above panel during a re-link, nor do you get the above panel during a re-fresh. Nor do you get the above panel if you select a existing DSN. You MUST create a new DSN to get/see/use the above panel. It ONLY appears one time, and ONLY during the time you create a new DSN - not during re-use or a re-link or a re-select of a existing DSN.
Wow, this takes me back.
Assuming you're using an ODBC DSN to set the connection for the linked tables, set the ODBC data source to use the "SQL Server Native Client" driver, not the "SQL Server" driver. As I recall you can't change the driver for a DSN, so you'll have to remove your existing one and create a new one.
To get there:
Open start menu > type "odbc data sources" > click to open odbc data sources > click add > scroll all the way to the bottom of the drivers list and choose SQL Server Native Client as the driver > set up the rest of the DSN according to your environment.
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
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.
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.