Page 1 of 1
Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 11:03
by brace
Hello,
this issue is very important to me.
I deployed the latset version of my application to a customer that always used succesfully the old releases.
Now he gots on same TMSQuery.Open the following error:
MSQuery1: type mismatch for field DisplayLabel: expecting Date actual : Wide string
now there is no type mismatch and the exe works perfectly on other machines, the problem is only a this customer's end.
Since sql server is installed on a very busy machine (full of softare and with low resources, like only few MB of hard disk are available on C drive) my question is:
is it possible that a type mismatch error comes because of the server?
Note: runing the exe on the server works fine, the problem is only when the exe runs on a client machine.
If you have any other idea please tell me.
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 11:58
by AndreyZ
This problem is caused by the OLEDB provider. OLEDB provider returns DATE columns in the string format, and this causes the problem with date format. When there is no SQL Native Client provider, SDAC uses OLEDB provider. To solve the problem, you should install SQL Native Client provider on all machines where you encounter the problem with DATE columns.
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 13:06
by brace
Thanks for the reply.
i will try as you suggest with Native Client, could you please tell me a downlaod link for an installer for sql server native client 2008? And 2008 R2 is the same? By searching on google I just fine fake sites.
But do you have an idea of why this behavior suddenyl appeared? Before installing the new release of my application all was ok, after no. And I didn't change the way SDAC is used, it was just a small release with minor improvements.
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 14:06
by AndreyZ
You can download SQL Native Client 10 at
http://www.microsoft.com/en-us/download ... x?id=30440 . Also, SQL Native Client 10 is shipped with SQL Server 2008.
There are two reasons why you did not encounter such problem before:
1. you did not use persistent fields (most probable);
2. you did not work with DATE columns.
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 16:16
by brace
The solution worked.
Anyway I am VERY WORRIED, I found the same problem on another machine with WIN xp sp 3.
Most of my customers have xp, so if all them must run native client installer they will blame me. I tried on 3 more XP machines and on 2 i found it.
I really don't understand why this started now, before I had 6.1.4, now 6.1.6.
Did you change something in the logic of how sdac uses OLEDB?
Help!
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Wed 19 Dec 2012 17:20
by brace
Hello, yes the problem was DATE in db, I always used DATETIME and this time I used DATE.
I am happy so now I know why I had the problem.
I ould be good that SDAC takes carea of "DATE to string" problem to avoid using naative client. This is important I think.
Re: Possible reason of Type Mismatch error in a specific amchine only
Posted: Thu 20 Dec 2012 10:56
by AndreyZ
You can avoid this problem (when the OLEDB provider is used) using the Data Type Mapping feature (SDAC supports it since version 6.2.7). Here is a code example:
Code: Select all
MSQuery1.SQL.Text := 'select fieldname from tablename'; // fieldname has the DATE type on the server
MSQuery1.DataTypeMap.AddFieldNameRule('fieldname', ftDate);
MSQuery1.Open;
ShowMessage(MSQuery1.FieldByName('fieldname').ClassName); // here you will see the 'TDateField' message
For more information about the Data Type Mapping feature, please read the "Data Type Mapping" article in the SDAC documentation.