Hello VB programmers,

I'm in a great situation where I have access to SQL Server. I would like
to know where and how can I start learning Remote Data Objects. If you
could point me to what books or Internet articles that might help me.

Thanks for all your help.

cesar

Good luck there is not much documentation on the topic.. If you have
access to technet od developers taht is your best bet.  There is a
book though call VB & SQL servers Hitchikers Guide that has helped me
out quite a bit.  Check is out..

Kev.-

Don't bother learning RDO.

It's still full of bugs.

Sure there are lots of articles out ther, but all written by theorists.

Anyone having success with RDO please disagree now.

Robson), wrote these mellifluous words, full of wisdom and thoughtful
reflections:

I have about 9 months professional experience using the RDO/MSRDC (the latter to
obtain the listing of records in a grid), and very few real problems. I mean,
there are certain glitches here and there, but on the whole it is quite possible
to work with it. It is also a better choice, if your project is supposed to work
in heterogenous database environment.

There's certainly a lot of academia hype around RDO, as well as there is around
the OO programming style. In my opinion, they may call it whatever they like,
but if I can develop faster apps in shorter time, what do I care about the tag?

by any other name would smell as sweet... (Sorry for intentional distortion).

What happens in RDO depends on where you place the cursordriver (on
the workstation or on the server)  what rowsetsize you use, and
whether you make full use of rdopreparedstatements which work
flawlessly once you understand them. I

We are working on a major rdo project and have been at it for about 3
months now. We made all the usual errors at the start and got very
disillusioned but the whole thing is running beautifully now. We have
mad great use of stored procedures to split the processing between the
workstations and server and have kept row counts down to about 100.

I'm an rdo fan!!!! :-)

I seconf the recommendation for Hitchhiker but it won't  teach you rdo
- its a refernce book. The only way to learn it at present is by trial
and error - unless I can find time to write a tutorial!
--
Doug Gibbard,
Lincoln England

  Since you have trialed and errored your way through RDO (I have begun
but not yet reached Master Status.. ;)), could you help me with a problem??

I have a functioning RDO application running on an NT server but would
like to make the routines more re-usable.  I am therefore created a library
of routines that I am putting in a class for re-use.  I had discovered to
evils of automatic prepared statements and the need to get rid of them
once they were no longer needed.  Now that I am putting this code in
a class I come to need to determine exactly WHICH PreparedStatment
was used to generated a passed ResultSet.  I have searched and
searched.  I thought it would be the hStmt parameter but that does not
seem to match when I pass a simple test to the class, ie: one ResultSet
created by one PreparedStatement on a connection.

Any clues as to how to determine the PreparedStatement to close when
attempting to close a specific ResultSet?  Hopefully it will not be too
obvious and therefore openly displaying my inability to find things in the
docs...

Thanks to anyone who can help.

D.M.(Mike) Mattix
Monsanto Company
Luling, LA 70070

I am a long way frm master status - I've just been through some of the
mill! :-)

There are a number of ways of doing this and I am working from memory
rather than having refreshed my mind from the code:

a. Loop through the rdopreparedstatements collection using the name
attribute: so-

for each ps in {rdoConnection name}.rdopreparedstatements
        if ps.name = "Select * from Orders" then
                ps.close
        end if
next ps

b. Number all rdopreparedstatements as they are created: so

dim iPsOrders as integer
set iPsOrders to -1 at start and end of scope

if iPsOrders = -1 then
        Set PsOrders = {rdoConnection name}.CreatePreparedStatement
("", "Select * from Orders))
        iPsOrders = {rdoConnection name}.rdopreparedstatements.Count
-1
endif

you can then close by testing iPsOrders and then closing (and setting
the flag back to -1 or everything will get out of sync) if a positive
value. This has the added advantage of not recreating the
rdoPreparedstatement every time the code runs past it as it will only
fire if iPsOrders is set. If you have too many ps going at once you
will fill SQL Server tempdb (Are you using SQLServer?) or your project
database and slow things up. Use sp_who to see what is active at any
time. You will get quite a shock when you see storedprocedures (which
is what rdoprepared statements create - temporary ones that is ) still
opened which you should  have closed.

We use 'b' above with all rdoresultsets loaded from preparedstatements
so that the resultsets are not reloaded (and the count incremented)
every time the code is passed. You need to close both the prepared
statement and the resultsets which are loaded from them when they go
out of scope. They will stay on the server / workstation otherwise.
You  can use 'a' for this as well if you wish but it is very texty
(but see below about resource files). It is however the safest way.

In you case I would set a number for each prepared statement and
resultset. We close all ps and rs when we have finished with them and
move on to another part of the program ie when we get back to a blank
mdiForm. Your idea sounds interesting but do check every now again by
looping through the collections and printing out the names or
msgboxing them to ensure that the close algorithm is working properly.

BTW we use a Visual C++ resource file for all our prepared statement
string and then call:

Set PsOrders = {rdoConnection name}.CreatePreparedStatement ("",
LoadResString(51))

This is much more memory efficient and avoids the same string
appearing all over the place as team members create new ones. It acts
as a good catalog. If you are using the names technique you can then
test in the close loop at 'a' above using:

        if ps.name = LoadResString(51) then

Hell - I've gone on a bit but hope it helps - I apologise if there are
any errors in the above syntax - the project is on NT and this is
being written in '95 and I'd have to reboot. Let me know if I can help
further - I am leading a team writing a Police Internal Affairs system
for up to 43 UK Police Forces and its all on RD0 and working! Devil
take the Unbelievers! :-)

Doug
--
Doug Gibbard,
Lincoln England

Are we both using the same VB?  I tried doing the simplest thing in RDC and
I can't get it off the ground without crashing and burning: select * from
some_table into a grid.

* When you add new rows, delete them the data control gets totally confused
(especially if there's an error because of a trigger or foreign key
restrictions).

* you sometimes can't access specific rows or columns!

* a more complex select statement (with **ooh** outer joins **ahh**) just
completely craps the damned thing out.

* It leaks memory like there's no tomorrow.

* it leaks hstmt-s to SQL server.  Just run sp_who...  Open your form, run
sp_who again...  Close the form, run sp_who....  Yikes, there's a bunch of
{*filter*}left!  Just do this a couple of more times and you're hung out to dry.

These are not "simple bugs", this prevents this tool to be used in any kind
of real way in the REAL world.  I know ODBC is a slow SH*T, still it's
reliable and it WORKS.  I'd rather have my users complain that my app is
30% slower than have to come by every day and figure out a new workaround
for each GPF the app gets (usually because the system ran out of
resources/memory/HSTMT).

Ofer.

You are absoultely right.  The "simple bugs" in RDO prevent it from being used
in any real application.   Answers to my previous posting implied that I was
just a newbie and did not have enough ecperience.  Not true, I did my oracle
training in 1987 etc etc.  I have a very strong data modelling and db design
experience, as well as years of fortran and QuickBasic before getting into VB4
and RDO.

What my mistake perhaps was that I got into RDO from the day we got our VB4
Enterprise edition, before last Christmas.  RDO was the answer to our prayers,
the client/server with an easy front end like VB going to an industrial
strength RDBMS server like Oracle.  When it played up merry hell, despite hours
of trying all the combinations, I was surprised there was no discussion on this
newsgroup (back in March-April-May-June 96). It is only in the last six weeks
or so that the postings have really started to flow.  I felt I was a lone voice
yelling for help previously.  Not being a C programmer, I didnt know then about
memory leaks etc.  I just thought RDO would work as described as in the help.

Incidentally, I printed out all the help and reference articles to get a
complete reference manual (which I read cover to cover).  However, it should be
read as a specification for what is proposed, not what actually works.  

RDO is the greatest con on the corporate buyers of VB one can ever imagine - it
and Visual Source Safe are meant to be the tools to develop robust, large scale
Enterprise (their word) client/server apps in VisualBasic.   Note especially
the lack of working examples in the help, compared with the more established
parts of VB.  Conclusion - the help was written before the RDO product was
tested.

I can only ask that every user keep posting problems and demanding that
troubles be fixed.  Oracle themselves have just released a rival version called
Oracle Objects, perhaps this will make the Oracle users happy and create some
competition in the marketplace.

Grrrrrr,

Brian Robson  (Bondi Beach, Sydney Australia)

I guess if the alternative is the ODBC API then using RDO in the unbound
mode could/should be an alternative...

D.M.(Mike) Mattix
Monsanto Company
Luling, LA 70070

I too fight with RDO every day, I've tried the following ODBC drivers
Intersolv (sucks), Visigenic (They said its not worth sending to me for
RDO),\
OpenLink (Not bad but default parameter type to varchars}, Simba just
starting to test!

Good luck and let me know if you find success!

Just an FYI.  The memory problems have been fixed so they say.  But
you have to get the bug fix - MSRDO32.dll from MS web site and also
have VB 4.0a.

Kev.-