Very Computer

Hi Folks

I have just taken over maintenance of an app that uses RDO.

Now, I have never used RDO before, DAO and ADO, yes, but never RDO.

Is there an easy and reliable method of checking the status of the database
connection as you can in ADO? I have searched the MSDN but it is pretty
unhelpful on that subject (unusual that).

Cheers

Paul BJ

I haven't used RDO since 1998, so I have nothing very useful to say, but
another alternative that you could at least consider, is changing the app to
use ADO instead of RDO, but depending on the size of the project, that very
well could be a bad idea.

--
Peace and happy computing,

Mike Labosh, MCP, MCT, MCSD
"Hit any user to continue."

Yes, that was my reaction exactly, its only a small app and we have to add
significant functionality so the overhead of doing the conversion (to a
technology that I am familiar with) would be minimal in the context of the
overall spend. However when I suggested doing just that, my boss muttered
darkly that my predecessor had already tried it and failed; although he
didn't know why!

One of the DBs we have to connect to is on a remote network that belongs to
someone else and its a Sybase System 11 animal. One of the problems may have
been that we don't have any OLE DB drivers for this DB as we ourselves don't
use it. Obviously we have some kind of ODBC driver (from Merant I think)
that manages the current connectivity but whether that includes an OLE DB
driver I am not sure. I guess we could use ADO with the existing ODBC kit
but I am not going to win any prizes for popularity if I try it, hit
problems and waste days and days trying to sort them.

Cheers

Paul BJ

Quote:> I haven't used RDO since 1998, so I have nothing very useful to say, but
> another alternative that you could at least consider, is changing the app
to
> use ADO instead of RDO, but depending on the size of the project, that
very
> well could be a bad idea.

> --
> Peace and happy computing,

> Mike Labosh, MCP, MCT, MCSD
> "Hit any user to continue."

Quote:> overall spend. However when I suggested doing just that, my boss muttered
> darkly that my predecessor had already tried it and failed; although he
> didn't know why!

Politely inform your boss that s/he is a heretic, and then use the OLE-DB
provider for ODBC.  ;)

--
Peace and happy computing,

Mike Labosh, MCP, MCT, MCSD
"Hit any user to continue."

The database that we have to address (sensibly) denies all table access so
all reads are done using views and all writes employ stored procedures.

I remember when I first started writing ADO code having the Devil's own job
getting a writable recordset back from a call to execute a stored procedure.
I started off using Microsoft's own example code which makes use of a
command object and as far as I can recall, the command object can only
return a read only recordset . Somewhere buried deep within the bowels of
the MSDN was some code that would have done the job for me but the MSDN is
now so large and so badly indexed that is almost impossible to find the
simplest thing.  In the end, I posted a query on a newsgroup and a guy who
works in a firm who had called in Microsoft Consultants to write their ADO
code delved into the data access classes that they had written and sent me
an extract of code that demonstrated how to use a command object to send
parameters to the database in combination with recordset .Open resulting in
a writable recordset .

My best guess is that the person who attempted unsuccessfully to use ADO to
do this job was unaware of how to get a writable recordset from a stored
procedure call using a command object.

Cheers

Paul

Quote:> > overall spend. However when I suggested doing just that, my boss
muttered
> > darkly that my predecessor had already tried it and failed; although he
> > didn't know why!

> Politely inform your boss that s/he is a heretic, and then use the OLE-DB
> provider for ODBC.  ;)

> --
> Peace and happy computing,

> Mike Labosh, MCP, MCT, MCSD
> "Hit any user to continue."