Possible reason of Type Mismatch error in a specific amchine only

Discussion of open issues, suggestions and bugs regarding SDAC (SQL Server Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
brace
Posts: 213
Joined: Wed 14 Feb 2007 08:26

Possible reason of Type Mismatch error in a specific amchine only

Post by brace » Wed 19 Dec 2012 11:03

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.

AndreyZ

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by AndreyZ » Wed 19 Dec 2012 11:58

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.

brace
Posts: 213
Joined: Wed 14 Feb 2007 08:26

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by brace » Wed 19 Dec 2012 13:06

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.

AndreyZ

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by AndreyZ » Wed 19 Dec 2012 14:06

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.

brace
Posts: 213
Joined: Wed 14 Feb 2007 08:26

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by brace » Wed 19 Dec 2012 16:16

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!

brace
Posts: 213
Joined: Wed 14 Feb 2007 08:26

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by brace » Wed 19 Dec 2012 17:20

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.

AndreyZ

Re: Possible reason of Type Mismatch error in a specific amchine only

Post by AndreyZ » Thu 20 Dec 2012 10:56

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.

Post Reply