Hello,

We have a program that connects to a SQL Server database. There are
several BIGINT fields in the database. To retrieve data from one of the
fields, we use the following code:

function GetBytesAsMB: Real;
begin
Result:=DMMSSQL.QryServers.FieldByName('BytesPerLimit').AsFloat/1048576;
6; end;

Now, for 90% of our customers, this works just fine. We can't retrieve
using "AsInteger" because the number can easily be larger than the number
supported by the Integer type. However, a few installations return the
following error:

  exception class   : EOleException
  exception message : OLE error 80040E21.

The exception is raised at line 4199 in ADODB.pas:

   DataConvert(Field, @C, Buffer, True) else

First question: Is there a SQL Server setting that could be preventing
this from working?

Second question: Is there a safer way to do this?

Thanks,
Dan

On 9/12/2006 4:29:16 AM, "Guillem" wrote:
>
>my suggestion: check if the OLE DB provider is the same you have on
>those computers where it works.
>
>Also check if the MDAC version is the appropiate and/or is broken in
>those computers where it fails. For this you can use
>
>http://www.microsoft.com/downloads/details.aspx?FamilyId=8F0A8DF6-4A21-4
>B43-BF53-14332EF092C9&displaylang=en
>
>or 
>
>http://tinyurl.com/62nvo
>
>For example, it could be you have MDAC 2.8 SP1 installed on the
>machines where it works and MDAC 2.8 on the machines where it doesn't
>work. There is really a difference if the SP is installed or not, as we
>discovered some time ago... sigh
>
>Also check my reply to John. I hope something of all this can help you
>

Thanks for the link to the component checker. I'd not seen that before
and I think it will be really useful. I saw your reply to John and might
try that, but reading the data using AsVariant into a Real variable seems
to have worked. Again, thanks for your help.

Dan

Dan Cumpian wrote:


> 
> I saw those on Google and they really didn't point to a specific
> problem or workaround. I think I'll try reading the data using
> AsVariant and see if that will solve the problem. I'm not sure what
> else to try.
> 
> Thanks,
> Dan

my suggestion: check if the OLE DB provider is the same you have on
those computers where it works.

Also check if the MDAC version is the appropiate and/or is broken in
those computers where it fails. For this you can use

http://www.microsoft.com/downloads/details.aspx?FamilyId=8F0A8DF6-4A21-4
B43-BF53-14332EF092C9&displaylang=en

or 

http://tinyurl.com/62nvo

For example, it could be you have MDAC 2.8 SP1 installed on the
machines where it works and MDAC 2.8 on the machines where it doesn't
work. There is really a difference if the SP is installed or not, as we
discovered some time ago... sigh

Also check my reply to John. I hope something of all this can help you

-- 
Best regards :)

Guillem Vicens Meier
Dep. Informatica Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam

John Herbster wrote:

> 
> Dan,  I hope that I fixed the above correctly.

?

> 
> I am not familiar with ADO, but I assume that BIGINT is 64-bits
> signed integer, and that ADO does not allow reading as such.

I have not used MS SQL Server so I can't really tell what BIGINT is but
I would like to think that ADO *can* handle it, since it is the native
component set for that RDBMS...

> 
> 
> As far as a work-a-round, can you bypass the AsInteger
> and AsFloat and read the 64-bits out of the record buffer
> as bytes?  If so, then you could convert the 8-bytes directly
> into 8-byte buffer and from there directly into an Int64
> integer type.
> 

this remembered me something and after digging a bit I think Dan could
try to use following:

function GetBytesAsMB: Real;
var
   number : Int64;
begin
   Number :=
TLargeIntField(adodataset1.Fields.FieldByName('field')).AsLargeInt;
   Result := Number / 1048576;
end;

-- 
Best regards :)

Guillem Vicens Meier
Dep. Informatica Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam

On 9/11/2006 5:28:45 AM, "Guillem" wrote:
>Dan Cumpian wrote:
>
>> OLE error 80040E21
>
>can't find any good reference to it in MSDN but
>
>http://tutorials.aspfaq.com/8000xxxxx-errors/why-do-i-get-80040e21-error
>s.html
>
>Although it is an ASP FAQ it gives you some possibilities to check.
>
>http://www.mssqlcity.com/FAQ/Trouble/error_80040e21.htm
>
>this gives you another possibility to check.
>
>I would bet it is an OLE DB provider error.
>
>Good luck

I saw those on Google and they really didn't point to a specific problem
or workaround. I think I'll try reading the data using AsVariant and see
if that will solve the problem. I'm not sure what else to try.

Thanks,
Dan

Dan Cumpian wrote:

> OLE error 80040E21

can't find any good reference to it in MSDN but

http://tutorials.aspfaq.com/8000xxxxx-errors/why-do-i-get-80040e21-error
s.html

Although it is an ASP FAQ it gives you some possibilities to check.

http://www.mssqlcity.com/FAQ/Trouble/error_80040e21.htm

this gives you another possibility to check.

I would bet it is an OLE DB provider error.

Good luck
-- 
Best regards :)

Guillem Vicens Meier
Dep. Informatica Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam

"Dan Cumpian"  wrote
> We have a program that connects to a SQL Server database. There are
> several BIGINT fields in the database. To retrieve data from one of the
> fields, we use the following code:
>   function GetBytesAsMB: Real;
>   begin
>   Result := DMMSSQL.QryServers.FieldByName
>       ('BytesPerLimit').AsFloat/1048576;
>   end;

Dan,  I hope that I fixed the above correctly.

> Now, for 90% of our customers, this works just fine. We can't
> retrieve using "AsInteger" because the number can easily be
> larger than the number supported by the Integer type.
> However, a few installations return the following error:
>   exception class   : EOleException
>   exception message : OLE error 80040E21.
> The exception is raised at line 4199 in ADODB.pas:
>   DataConvert(Field, @C, Buffer, True) else

I am not familiar with ADO, but I assume that BIGINT is 64-bits
signed integer, and that ADO does not allow reading as such.

Trying to convert such a 64-bit signed integer into a "double"
(which is what a type "real" usually is defined as) is problematic.
The double has only 52 or 53 significant bits not counting the
sign and exponent. Further, if ADO does not recognize the
BIGINT, then I would suspect that there could be other
problems with the conversion.

The conversion to AsFloat can also fail if the FPU's control
word (CW) is set incorrectly by Windows or some other
code within your program.  You can check this by examining
the control word before the point of the AsFloat with a
Get8087CW call.  It should return $1332 (that's hex) or
$1372.

As far as a work-a-round, can you bypass the AsInteger
and AsFloat and read the 64-bits out of the record buffer
as bytes?  If so, then you could convert the 8-bytes directly
into 8-byte buffer and from there directly into an Int64
integer type.

HTH, JohnH