On Jun 1, 1:15 pm, GregD <[email protected]> wrote:
> I finally got back to this and I still can not get it to work. I'm
> going to try some real basic stored proc stuff like a proc that just
> selects a literal as a column_name and see if I can get any type of
> success.
OK. If even the simple stuff isn't working, there may be an issue
with using stored procs on Sybase. I've only tested the JDBC stored
proc code on MySQL, though I have had reports of other people using it
successfully on other databases.
> > Honestly, Sequel's built in support for stored procedures isn't very
> > extensive. For example, it doesn't handle IN/OUT parameters, and it
> > is only supported on MySQL and JDBC. If your database is a heavy user
> > of stored procedures, Sequel built in support may not be enough.
> > That's not saying you shouldn't use Sequel at all. But it may be best
> > to access the database connection directly to run the stored
> > procedures:
>
> > DB.synchronize do |conn|
> > conn.execute_stored_procedure(...)
> > end
>
> Well, from java where we call the procs we don't use any extensive
> stuff. we just expect a resultset. Many are just an ErrMsg column to
> be evaluated.
>
> I tried the above code and the execute_stored_procedure is an unknown
> method. Was I suppose to write that method or use a Sybase java
> library class method?
execute_stored_procedure was purely illustrative. conn would be a
JDBC connection objection object, so you should use whatever JDBC
connection method you need. Sequel uses prepareCall with "{call
procedure_name(?, ?)}" and uses bound variables for the arguments, so
if that doesn't work on Sybase, that would explain things.
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
