Jeremy, One more question(s). Probably not the last.
A lot of these stored procs have a standard of returning a single record with a single column with an error message in it. I'd like to capture this in a Sequel::Model class. Can you have Sequel::Model not be associated to a database table? How would you cast (not the right word) the dataset created from the call_sproc to this Sequel::Model class? Thanks, GregD On Jun 2, 1:59 pm, GregD <[email protected]> wrote: > 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.
