ADO handling disconnections

[markphsd]

Hi,

I would like to know how to determine if the connection object is valid, before using it.

Invalid wouldn't necessarily mean, adStateClosed, because i can turn off my wireless device on my computer and ado won't recognize this. Then when i try to open a recordset i get an error.

I believe need some kind of withevents for a change of the connection objects state, it doesn't seem to recognize shutting off the wireless as a change in state. Also, the object is still not nothing after turning off the device. So I don't know!

HELP
thanks

Mark P.

http://www.cafecartel.com

Providing Low Cost Powerful Point of Sale Solutions.

 

[BobRodes]

< The scarcity of information on this event suggests it doesn't have much practical value

Now, Joe, if you're saying that the amount of information available about something is proportional in any way to its practical value, one need only mention the name Paris Hilton to refute the assertion out of hand.

Seriously, though, I'm sure you've seen plenty of strongm's and Hypetia's posts that suggest that such an assertion simply doesn't hold water.

Bob

 

[JoeAtWork]

OK, I was looking for a short phrase to avoid a longer explanation.

Despite your Paris analogy, I think the number and quality of Google hits for a search on a technical term really does reflect it's value within it's related technology.

Knowing for example how valuable the ADO Errors collection can be for a programmer, I can reasonably expect that a search on "ADO Errors Collection" will return numerous hits, and many of the links will probably include in-depth explanation and examples of using this collection

In contrast, my search for "ADO Disconnect event" gave very few relevant links, and most of those had one or two line descriptions similar to MSDN's "The Disconnect event is called after a connection ends". The fact that on the entire Internet nobody thought it was worth much more discussion beyond that led me to make my "not much practical value" comment. Maybe I should have said something like "only useful for highly specialized purposes".

So, I just wanted a short way of saying all of the above.
Unfortunately I don't have StrongM's talent for the laconic yet accurate reply.

 

[BobRodes]

I'm hearing you Joe, and I don't really believe that you have no point at all. However, I've found that some very valuable stuff has very little documentation, for example that stuff about TOM that strongm "keeps banging on about in the forum."

Another example from my own research in ADO would be the Optimize property (adoRS.Fields("myField").Properties("Optimize")), which creates a dynamic index on a field in an ADO recordset, and took me quite a while to find. I dont' know why; you would think that people would be dynamically indexing ADO recordsets for performance pretty often. Anyway, I found that it gave me about a 1000% performance boost in a situation where I was iterating through two recordsets to populate an individual line item, itself derived from a third recordset, in a listbox.

Now, it's possible that, like data binding, the Disconnect event has some real weaknesses that make it a bad idea to use, but it's also possible that it's not in style or something. After all, how many times have you seen that data binding is a bad idea? Maybe if the Disconnect really were a bad idea, you'd have read some horror stories about it.

So, while I take your point, I take it with a medium-sized grain of salt.

Finally, of all the posts on this thread, I suspect that SBerthold's show the most insight into the actual problem.

Bob