Jeremy,

It seems to be working with DB.dataset.call_sproc(type, name, *args).
I'm novice when it comes to ruby and was passing the wrong thing in
for the args.  I had a hash as the valid args and merged in override
hashes for the particular tests.  Then I converted the values of the
resulting hash into an array.  I forgot to proceed the array with an
asterisk.  Once I did that, it works.

This is starting to look very promising to use Sequel to unit test our
stored procs.  Hopefully, it will lead us to the promise land =>
functional testing and then to more ruby scripting for coding
monkeybars MVC and eventually less stored procs.

Thanks for putting up with my novice questions,

GregD

On Jun 1, 5:24 pm, Jeremy Evans <[email protected]> wrote:
> 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.

Reply via email to