TADOConnection CommandTimeout Help

[James Franchello]

Hello,
I am using MS-SQL 7.0 with a Delphi 5 app to execute stored procedures. I
cannot seem to get the CommandTimeout to have any affect - once the ExecSQL
command is executed there appears to be about 30 seconds before the timeout
exception is encountered. Can anyone point me in the right direction?
TIA, James

[Vassil Nazarov]

Use a TADOCommand instead which has a CommandTimeout
property.

--
Vassil Nazarov
http://web.orbitel.bg/vassil/

[James D. Franchello]

Thanks Vassil!
I made the necessary code changes and have successfully tested in my
test environment but I won't know what kind of success I have had until
I test it at the client location. One more question for you: what on
earth is the commandtimeout for on the TADOConnection if not for
precisely this purpose? And, any idea why it doesn't seem to work?
TIA, James

[Vassil Nazarov]

The connection's CommandTimeot property is meant to work in conjunction
with the connection's Execute method only. This however is not a
recommended practice for everyday use.

[James D. Franchello]

I don't mean to be a pest about this but I really don't understand what
is happening here. I was using the ExecProc of TADOStoredProc to execute
a stored procedure (that seemed appropriate!) but the neither the
CommandTimeout property of the TADOStoredProc nor of the TADOConnection
have any affect on actually extending the timeout! Is there a bug here
somewhere or am I really missing the boat (the later being a distinct
possibility!).
Thanks again for your time and patience!
James

[Vassil Nazarov]

James,

TADOStoredProc doesn't have a CommandTimeout property.
It was overlooked by Borland and that's why you have to use the
more appropriate TADOCommand. Alternatively you can use
the following typecast :

TCustomADODataSet(ADOStoredProc1).CommandTimeout := 60;

The connection has nothing
to do with this and was never meant to. If you are wandering why
the connection object has a CommandTimeout property you can
find the following in the MDAC help:

<snip>
The CommandTimeout setting on a Connection object has no effect
on the CommandTimeout setting on a Command object on the same
Connection; that is, the Command object's CommandTimeout property
does not inherit the value of the Connection object's CommandTimeout
value.

Note To execute a query without using a Command object, pass a query
string to the Execute method of a Connection object. However, a
Command object is required when you want to persist the command text
and re-execute it, or use query parameters.

--
Vassil Nazarov
http://web.orbitel.bg/vassil/

"James D. Franchello" <ja...@intinfo.com> wrote in message news:3B713F...@intinfo.com...

[Thérèse Hanquet]

Hi Vassil,

> Alternatively you can use
> the following typecast :
>
> TCustomADODataSet(ADOStoredProc1).CommandTimeout := 60;

I forwarded your answer to Sergei who asked about the same problem
(thread of 09/08). However he reminded me that CommandTimeOut is
protected in TCustomADODataset. Did you mean
TADODataSet(ADOStoredProc1)?

Thérèse

PS Sorry I sent this first to your private email by error.

[Vassil Nazarov]

Hi Thérèse,

> I forwarded your answer to Sergei who asked about the same problem
> (thread of 09/08). However he reminded me that CommandTimeOut is
> protected in TCustomADODataset. Did you mean
> TADODataSet(ADOStoredProc1)?

I wrote that from memory only but Sergei obviously has a point.
TADODataSet(ADOStoredProc1) should work just fine. Thanks.

[James D. Franchello]

Vassil Nazarov wrote:
>
> James,
>
> TADOStoredProc doesn't have a CommandTimeout property.
> It was overlooked by Borland and that's why you have to use the
> more appropriate TADOCommand. Alternatively you can use
> the following typecast :
>
> TCustomADODataSet(ADOStoredProc1).CommandTimeout := 60;
>

Hello again Vassil,

Thanks again. I'm sorry I haven't posted this earlier but I have been
away for a few days since my last post. I also saw the post from Therese
and your response. I am not sure I know exactly how to ask my next
question other than to say: how does the type cast to TADODataset
actually work here? I think I am confused because TADOStoredProc and
TADODataset both descend from TCustomADODataSet (that has a protected
CommandTimeout property so I cannot get at it) but TADOStoredProc and
TADODataset appear to me to be "not related" so I would never have
thought to try this type cast. It would seem to me that I would simply
be "tricking the compiler" but not actually setting the property at
all! It seems to me to be like "inventing" a non-existent property for
an object! Now, you have been extremely patient and generous with your
time so my feelings won't be hurt if you tell me to "go read a book"!
Question is: what book am I going to find these sort of answers in???

Many thanks again,
James

[Thérèse Hanquet]

Hi James,

> I am not sure I know exactly how to ask my next
> question other than to say: how does the type cast to TADODataset
> actually work here? I think I am confused because TADOStoredProc and
> TADODataset both descend from TCustomADODataSet (that has a protected
> CommandTimeout property so I cannot get at it) but TADOStoredProc and
> TADODataset appear to me to be "not related" so I would never have
> thought to try this type cast.

Maybe Vassil will have a more relevant answer, but all I can say is that I
use this kind of typecast in another context without problem.

I have a procedure which takes a TADODataSet as parameter. If the dataset is
in fact a TADOTable, calling MyProcedure(TADODataSet(MyADOTable)) works just
fine - don't ask me why...

Now my question: if you try that to solve the CommandTimeOut problem, does
it work?

Thérèse

[Vassil Nazarov]

> Now my question: if you try that to solve the CommandTimeOut problem, does
> it work?

It sure does. Check for yourself. <g>

ShowMessage(IntToStr(TADODataSet(ADOStoredProc1).CommandTimeout));
TADODataSet(ADOStoredProc1).CommandTimeout:=60;
ShowMessage(IntToStr(TADODataSet(ADOStoredProc1).CommandTimeout));

[Vassil Nazarov]

> It seems to me to be like "inventing" a non-existent property for
> an object!

It does exist. TADOStoredProc inherits it from TCustomADODataSet.
The problem is that it's declared in the protected section of the
ancestor and Borland forgot to move the declaration to the public
section of the descendent. So by the typecast you simply use the access
rights of TADODataSet to gain access to an existing but hidden property.

> Question is: what book am I going to find these sort of answers in???

As to the typecast, read the Object Pascal Language help. Look for words
like inheritance and polymorphism. For information on ADO get the MDAC
SDK from http://www.microsoft.com/data/download_260SDK.htm

HTH

[Thérèse Hanquet]

Hi Vassil,

> As to the typecast, read the Object Pascal Language help. Look for words
> like inheritance and polymorphism.

Thanks for the explanation.

I had looked into the Object Pascal Guide manual before answering James, but
I did not find any reference to this type of typecast (between two
descendents of the same ancestor). Looking for "inheritance" and
"polymorphism" does not seem to provide more information about this specific
point. Apparently typecasting is allowed only between classes that descend
one from the other - or did I miss something?

Also, if you use this syntax:
MyADOStoredProc as TADODataSet
the compiler will generate an error (incompatible types).

I agree it works... but I am like James, I am still not sure why.

Thérèse

[James D. Franchello]

Hi Thérèse,

> Now my question: if you try that to solve the CommandTimeOut problem, does
> it work?

As Vassil has shown it sure does work. The more I think about it the
more I think it is really a slick trick. I think I have a lot of reading
to do (and examples to look at) before I can say I fully understand it.
I have had a pretty simple minded view of inheritence until now so I
guess I owe it to myself to get a little more sophisticated.

Thanks for you help!
James

[James D. Franchello]

Hi Vassil,

Thanks for the eloquent and simple explanation! I will dig into this in
more detail as I believe I understand the concept better but not nearly
fully! I am interested to see how an inherited property is protected in
one incarnation and public in another. I must have been thinking that
the object doing the inheriting gets all or nothing as it is defined in
the ancestor (the simple minded view) but it is really built a piece at
a time by picking and choosing what to inherit and placing in the
"proper" section ... does that sound on the right track?

Thanks again!
James

[Vassil Nazarov]

> fully! I am interested to see how an inherited property is protected in
> one incarnation and public in another. I must have been thinking that
> the object doing the inheriting gets all or nothing as it is defined in
> the ancestor

It's really simple the descendent inherits everything (100%) from its
ancestor including the visibility and hiddenness of methods and
properties.

Class2 = Class(Class1)
End;

Class2 above is completely identical to Class1 in everything except for
its class name ancestor. Starting at this point, Class2 can basically do 3
things:
- Declare and implement new fields, methods and properties
- Override the visibility and/or implementation of inherited stuff
- Inherit / implement from other classes / interfaces

Class2 = Class(Class1, OtherClass, etc.)
....
//implement some useful stuff here
End;

See "Creating Custom Components" in Delphi help.