× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: IBM's ADO provider and numeric fields
  • From: "John Taylor" <john.taylor@xxxxxxxxxxxxxxx>
  • Date: Tue, 28 Nov 2000 16:51:16 -0700

Peter,

You may be current on the CA service pack, but what about database PTF's?
Host server PTF's?

I have a fair bit of code that relies on the ADO provider, and I'm not
having any problems with conversion of numeric variables.

Perhaps you should place a call to IBM support on this.


Regards,

John Taylor
Canada

----- Original Message -----
From: "Peter Dow" <pcdow@MailAndNews.com>
To: <MIDRANGE-L@midrange.com>
Sent: Tuesday, November 28, 2000 14:50
Subject: IBM's ADO provider and numeric fields


> Hi Everyone,
>
> Here we go again, at least if you saw my last episode. The problem is that
> IBM's ADO provider does not always translate numeric fields. Sometimes it
> works, sometimes it gives an error.
>
> I thought I had figured a workaround for the problem by changing my SQL
> statement from
>
>     SELECT * FROM PDOWD.RATEP
> to  SELECT RTCODE,RTDESC,RTAMT FROM PDOWD.RATEP
>
> However, when I added more fields after the RTAMT field,
>
>     SELECT RTCODE,RTDESC,RTAMT,RTGLNO FROM PDOWD.RATEP
>
> my VB program can no longer get the value for RTAMT (defined in the
physical
> file as packed 11.2). It gets the familiar "Invalid procedure call or
> argument" error. It occurred to me that maybe it could handle it if RTAMT
> was the last field in the select, so I tried
>
>     SELECT RTCODE,RTDESC,RTGLNO,RTAMT FROM PDOWD.RATEP
>
> and it worked. Then I tried rearranging the fields in the physical file,
and
> just for fun, threw in an extra amount field, so the file goes something
> like
>
>     RTCODE, RTDESC, RTGLNO, RTAMT1, RTAMT2
>
> with the values 1234.01 and 1234.02 for RTAMT1 and RTAMT2 in the 1st
record.
>
> Then I tried
>
>     SELECT * FROM PDOWD.RATEP
>
> and it got the correct value for RTAMT2, but for RTAMT1 it got
> 3094850098213450687247811042 which caused an overflow error since I was
> trying to put it into a Currency field.
>
> Is it really true that IBM's ADO provider for Win9x/NT has this blatant
> error in it? AFAIK, I'm on the latest CAExpress service pack, SF63638. Am
I
> doing something wrong? If so, it's sure not obvious what.
>
> TIA,
> Peter Dow
> Dow Software Services, Inc.
> 909 425-0194 voice
> 909 425-0196 fax


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.