[REBOL] Re: MSSQL results
From: gscottjones:mchsi at: 2-Oct-2002 6:23
From: "Franck MARCIA"
> Thanks, Scott.
> I already tried to send sql statements directly instead of using stored
> procedures... it didn't work (exactly, it worked the same as SP: there's
no
> error but Rebol "forgets" the second set of data - the second!).
Well, that is curious and seems to contradict the documentation. I am no
expert, but it is sounding like REBOL can only handle sending one request
and getting one table (dataset) back at a time, more like the following
(which I am assuming *does* work):
connection: open [scheme: 'odbc target: "bla bla bla"]
command: first connection
sql-orders: {SELECT * FROM orders where order_id = 1234}
insert command sql-string
sql-orders-blk: copy command
sql-orders-details: {SELECT * FROM orders_details where order_id = 1234}
sql-orders-details-blk: copy command
close connection
My SQL skills are rusty, but if you do not need to preserve the individual
table datasets, then I guess the other option is to do a table join. My
guess is that you are well aware of this, and are simply trying to access
MSSQL in a way that is similar to PHP (by the way, I could not find that
command *_next_result as in mydb_next_result in the PHP manual pages).
But I seem to be rambling...
> But I don't try to throw my computer through the window...
>
> ... is there a support from Rebol Corp? Perhaps Rebol can't do it!
OK, then you could donate your computer to a local charity, and then join a
monastic order :-)
... Or ...
Send a very nice email to feedback at rebol dot com stating your
observations and hope that maybe an RT employee will take mercy on your soul
and send you a definitive answer.
... Or ...
Send a request to cindy at rebol dot com requesting information on
commercial support.
... Or ...
Resubmit this very same question back to the mail list next week. Maybe a
different group of folks will be reading it, and know more about the issue.
If it were me and all the above had failed, I would simply make sequential
requests to the database, or use a JOIN, or if performance were critical,
make a new stored procedure that sends the join back, or make each SQL
statement into separate stored procedures. Just thinking out loud in case
you haven't explored some of these ideas.
If you find a solution, be sure to share it with the list. Invariably, some
one is going to ask the same thing, and it is nice to know. Good luck.
--Scott Jones
