Bill
I am not using Tango.. We really don't have a call
for it. At least not at this point.
Yes, I was meaning/wondering about executing a command
against tables (returning a recordset object through ADO).
From what I understand about ADO is that every time you
execute a statement against a ADO connection object your
are in effect creating a recordset object because this
is the way it's designed. I read this in a book by Bill
Vaughn on ADO... He reccomends not to do this unless
you have to, but in the sense that alot of what he
reccomends as better ways to do things are MS specific.
I know there are things that have to be done, and while
I am still investigating and learning about the most
basic and hopefully best ways to use ADO and Oterro
together, I know that I have to pay the price in some
instances and go on.
As far a Scott's command, I guess since I have not dug
into any of the Tango examples and related subject I
have missed some good stuff. I just plain didn't know
that you could execute an SELECT in this sense. I am
use to the debugger/environement tell me that I have
written unacceptable commands and I usually don't
attempt alternates without some specific info like this.
The one thing that gets me about all this is that
there isn't an easily accessible resource of info like
this. I wish RBase Tech. had more online/downloadable
information like this. I really appreciate all you guru's
putting stuff like this out on the list, cause this has
been a invaluable resource.
I'll look at your 99 confernce material and see some of
the things I have been missing.
Thanks
Jim Limburg
Bill Downall wrote:
>
> Jim,
>
> Do you mean the resource cost of hitting tables in the database? In
> my opinion, that's a pretty small cost.
>
> The advantage of the technique Scott described is that, by using a
> direct dbms action, which pretty much has to be an SQL command,
> you bring into play all of the functions available in R:Base, none of
> which are SQL features by themselves, but are specific to
> R:Base/Oterro.
>
> Scott used the most basic SQL command SELECT, and put an
> R:Base function in the expression following the work SELECT.
>
> The SYS_TABLE table has nothing in particular to do with the results.
> It could be any table name at all. Scott chose that one because he
> knows every database has a table with that name. He did not select
> any column information from the table. SELECT was just a syntax that
> works through Oterro. And SELECT has to have a table name in its
> syntax.
>
> On your copy of the CD from the 1999 Developers' Conference, I
> contributed some simple Tango (3.6) Application Files that took
> advantage of this technique. You would have to modify these for your
> own datasource, but the ones that use techniques like these are
>
> RPrompt.taf -- Most of the power of an R> prompt in your Tango
> application.
> dbSettings.taf -- A Tango equivalent of the SHOW command. Needs to
> be updated for new Oterro/R:Base settings in version 6.5.
>
> Manuel, in fact I used a successor to RPrompt.taf recently to fix a
> corrupted AUTONUM formula. Through the internet, I was able to type
> in AUTONUM col IN table DELETE and push the SUBMIT button, and
> then AUTONUM col IN table USING 1, 3567 and push the SUBMIT
> button.
>
> That's because AUTONUM is one of the commands available through
> Oterro, and the TAF was sending what I typed as a direct DBMS
> command.
>
> (RPrompt.taf is a dangerous TAF. Just as dangerous as an R> prompt.
> Build user-login security into it if you put it on a server exposed to the
> Internet, and change the name of the TAF, and maybe even put extra
> tests in for direct DBMS commands attempted that do not start with
> the word SELECT.)
>
> Bill
>
> On Mon, 24 Sep 2001 09:51:58 -0400, Jim Limburg wrote:
>
> >The other thing I wonder about this is when you executing
> >something like this are you going to the expense of
> >creating a record set when your using Oterro/RBase - ODBC.
> >I am thinking more in an Oterro environment through VB...
> >I know when you execute just a single Executable command
> >against through an ADO object your are doing this at the
> >expense of a creating a record set just for a quick
> >simple responce. I have used this method, but would like
> >to find better ways.
