I'm using ADO connection and ODBC driver to read DBF file:
Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;Extended Properties=dBase IV;
How can be string fields fetched without chars convertion (according to some codepage)? I mean, is there any way to read strings just like array of bytes.
Perhaps, some Property of ADOConnection or connection string advancing affects the behaviour of strings reading.
P.S.: Any dbf-file modifications are not acceptable.
I've already tried to advance connection string with the following parameters: "AutoTranslate=no;"; "CCSID=65535;". But it did not work. I still have characteres translation corresponding to some codepage
One more interesting moment. If to connect via OLE DB provider
Provider=Microsoft.Jet.OLEDB.4.0;Extended Properties=dBASE IV;
then chars translation is skipped.
But this method is slow and has some disadventages, therefore it doesn't fit well.
Currently, I have not found solution except using Jet OLE DB provider in case of incorrect strings autotranslation and MSDASQL provider as a common one for general purpose...
Related
I'm working on moving an old asp code to .net.
on the strCon (the connection to the database) one of the parameter is:
strCon=".....;CCSID=1255;"
I'm not sure what that means, I researched online but didn't find anything.
Can anybody explains what that means?
Per Wikipedia, CCSID means "Coded Character Set Identifier". Which sounds a little like "code page" and Windows has a codepage 1255 for Hebrew. If your application deals with text data that's in Hebrew, this may be the reason for it (but read the next paragraph!).
It may be legacy cruft left over from an old database or driver which handled different encodings via the connection string - it's not a standard parameter in SQL Server connection strings. See https://www.connectionstrings.com/all-sql-server-connection-string-keywords/ and https://msdn.microsoft.com/en-us/library/ms130822.aspx
Try removing that portion of the connection string; it may not be needed. The only way to be sure is to test.
Specifically, what character encoding does SQLDataSources use?
On my Windows 7 machine (set to New Zealand English) it seems to use CP1252. I can't find any mention of character encodings in the documentation.
It depends of database you use. For PostgreSQL I use SET client_encoding to <encoding>; after connecting do database. For Informix there is Client Encoding option available on Environment tab. For Oracle I use NLS_LANG environment setting.
I've done some experimentation and determined that data source names are in unicode. SQLDataSources gives you the name converted to the system code page, replacing characters that can't be converted with '?'. This is about as useful as you might expect. The undocumented function SQLDataSourcesW gives the name encoded in UTF-16.
I am having some trouble with a connection string between an ASP app sat on IIS and an existing SQL Server 2012 instance.
The current connection string that works is as follows:
Data Source=SERVER1;Initial Catalog=CORE;User
ID=testuser;Password=password;
MultipleActiveResultSets=true;Connection Timeout=200;pooling=false
The ODBC driver installed is SQL Server V 6.01.7601.17514. I then added the latest driver SQL Server Native Client 11 and tried adjusting the connection string in IIS with no luck.
I tried both ODBC and OLE DB strings from connectionstrings.com.
OLEDB
Provider=SQLNCLI11;Server=SERVER1;Database=CORE;Uid=testuser;Pwd=password;
ODBC
Driver={SQL Server Native Client 11.0};Server=SERVER1;Database=CORE;Uid=testuser;Pwd=password;
Each time I get a login prompt which I don't understand why the connection string is failing to supply these details with? What am I missing here?
Just having a look though some of the similar questions, some mentions named pipes which is enabled...
The first connection string is valid for the Net Framework Data Provider (the SqlClient classes), while the others are for the OleDb provider or ODBC provider.
Of course you should use the connection string that your provider understand.
If, in your code, you use the SqlClient classes (SqlConnection, SqlCommand) then you need to use the first connection string, if you use OleDbConnection or ODBCConnection you should use the others
See connectionstrings.com
I've always done it this way:
Data Source=;Initial Catalog=;UID=;PWD=;
I also recommend you put the connection string in a config file for easy editing like this: http://www.connectionstrings.com/Articles/Show/store-connection-string-in-web-config
Does Mono.Data.SQLite support in-memory databases using Shared Cache Mode? I'm getting an ArgumentException complaining about the format of the data source URI string. The connection string I'm attempting to use is:
URI=file::memory:?cache=shared;Version=3
I've also tried with the Data Source connection string property, with similar results.
(For reference, this is in the context of an iPhone MonoTouch application.)
I have the following code:
import pyodbc
cnxn = pyodbc.connect('DRIVER={IBM DB2 ODBC DRIVER};DATABASE=TDB2;UID=username;PWD=password')
I get the error message SQLSTATE=42705, which means that it cannot reach the database.
When I connect to DB2 using AQT, it states that the Database Name is DB2, Data Source Name is TDB2, DBALIAS=TDB2, ODBC driver is DB2CLI.DLL. Inside the database, I have some kind of "containers", which are listed in the category of "Database Objects", the containers contain Tables, and I believe that I need to specify this in my connection string as well.
I am completely confused about this. I do not even understand how AQT can connect to the database, without me providing an IP address, nor port number.
The solution was to remove the DATABASE=TDB2 and replace it with DBALIAS=TDB2.