The difference might be in the fact that you're using v12 ? I thought you're using v15 as well.

NO ! not same login, not same DB, not same Sybase.Data.AseClient.dll ,more over as you know each time I switch between V12 - V15 I have to change the Llblgen configuration file in order to use the rigth dll version; so I do work on V15!

I've tested the driver with [] and it works the same, so I've attached a new build of the driver with [] instead of _ so you can test it out on v12 to see if it fixes things for you.

thanks but I can't see any difference as you said

I've omitted to say that my driver is an already patched one (You sent it to me last week with IN / OUT proc. parameter direction patch ).

...

Otis wrote:

I've created a new proc, similar to an existing one but I replaced teh '_' with 'T', so instead of pr_GetEmployeeName, I have prTGetEmployeeName.

I get no errors whatsoever. Everything works.

Though you are right that '_' is used as a wildcard. sp_sproc_columns gives the parameters of all the matching procs.

However as sybase supports stored procedure overloading (with the ;_n_ suffixes) the parameter read routine checks the proc name and if it doesn't match to the current proc, it skips the parameter.

This thus gives no errors and the right parameters retrieved for the right procs.

So for v15, I don't see how this could go wrong (as I can't make it go wrong.. the sp_sproc_columns gives the proper results)

The difference might be in the fact that you're using v12 ? I thought you're using v15 as well. Anyway, the error you ran into in your startpost is thrown when 'scale' is read from the returned list of parameters. That value is returned by the sp_sproc_columns procedure, and as it's a smallint, it can either be a number (so convert will go ok) or NULL (which will make the routine skip, as it does on varchar parameters for example).

I've tested the driver with [] and it works the same, so I've attached a new build of the driver with [] instead of _ so you can test it out on v12 to see if it fixes things for you.

(the demo you have is the same code as we use, except the designer has some demo related protection code. The rest is the same, e.g. the drivers are the same so that's not it)

The difference might be in the fact that you're using v12 ? I thought you're using v15 as well.

NO ! not same login, not same DB, not same Sybase.Data.AseClient.dll ,more over as you know each time I switch between V12 - V15 I have to change the Llblgen configuration file in order to use the rigth dll version; so I do work on V15!

I've tested the driver with [] and it works the same, so I've attached a new build of the driver with [] instead of _ so you can test it out on v12 to see if it fixes things for you.

thanks but I can't see any difference as you said

I've omitted to say that my driver is an already patched one (You sent it to me last week with IN / OUT proc. parameter direction patch ).

...

(you can edit your own messages )

erl wrote:

Otis wrote:

I've created a new proc, similar to an existing one but I replaced teh '_' with 'T', so instead of pr_GetEmployeeName, I have prTGetEmployeeName. I get no errors whatsoever. Everything works.

Though you are right that '_' is used as a wildcard. sp_sproc_columns gives the parameters of all the matching procs.

However as sybase supports stored procedure overloading (with the ;_n_ suffixes) the parameter read routine checks the proc name and if it doesn't match to the current proc, it skips the parameter.

This thus gives no errors and the right parameters retrieved for the right procs.

So for v15, I don't see how this could go wrong (as I can't make it go wrong.. the sp_sproc_columns gives the proper results)

The difference might be in the fact that you're using v12 ? I thought you're using v15 as well. Anyway, the error you ran into in your startpost is thrown when 'scale' is read from the returned list of parameters. That value is returned by the sp_sproc_columns procedure, and as it's a smallint, it can either be a number (so convert will go ok) or NULL (which will make the routine skip, as it does on varchar parameters for example).

I've tested the driver with [] and it works the same, so I've attached a new build of the driver with [] instead of _ so you can test it out on v12 to see if it fixes things for you.

(the demo you have is the same code as we use, except the designer has some demo related protection code. The rest is the same, e.g. the drivers are the same so that's not it)

The difference might be in the fact that you're using v12 ? I thought you're using v15 as well.

NO ! not same login, not same DB, not same Sybase.Data.AseClient.dll ,more over as you know each time I switch between V12 - V15 I have to change the Llblgen configuration file in order to use the rigth dll version; so I do work on V15!

Ok!

I've tested the driver with [] and it works the same, so I've attached a new build of the driver with [] instead of _ so you can test it out on v12 to see if it fixes things for you.

thanks but I can't see any difference as you said

That's weird. The driver I attached in my previous post (v04172008 ) does replace _ with [_] in proc names send to sp_sproc_param! (but as I said, I didn't expect that to be the error).

I've omitted to say that my driver is an already patched one (You sent it to me last week with IN / OUT proc. parameter direction patch ). ...

Yes, that's right, but this driver is an updated one. So updated driver with param in/out, and the [_] code you suggested.

if this still fails, I'm really out of options, as I can't imagine what possibly could be wrong... We also haven't had any other reports about this either...

What I can do is append the proc name in the exception so the proc is known and the sp_sproc_columns output can be examined...

(edit). I've attached a new build which appends to the fatal exception test the proc name, the parameter name and the row number of the parameter in the set it got from sp_sproc_columns.

thanks for DLL. I have attached the result of sp_sproc_columns ps_aatest

here after the exception

Fatal Exception caught in SybaseAseSchemaRetriever::P opulateAllStoredProcedureParameters: 'Input string was not in a correct format.'. Proc in progress: 'dbo.ps_aatest;1'. Parameter in progress: '@login' at row: 1. Input string was not in a correct format.

-----[Core exception]-------------------- at SD.LLBLGen.Pro.DBDrivers.SybaseAse.SybaseAseSchemaRetriever.PopulateAllStoredProcedureParameters(AseConnection openSybaseAseConnection) at SD.LLBLGen.Pro.DBDrivers.SybaseAse.SybaseAseSchemaRetriever.RetrieveSchema(String connectionString, IDBSchema schemaToRetrieve, SchemaFetchFlags fetchFlags) at SD.LLBLGen.Pro.DBDrivers.SybaseAse.SybaseAseCatalogRetriever.RetrieveSchemas(String connectionString, IDBCatalog catalogToRetrieve, SchemaFetchFlags fetchFlags) at SD.LLBLGen.Pro.DBDrivers.SybaseAse.SybaseAseDBDriver.PopulateSelectedCatalogs(Hashtable callBacks, Hashtable connectionElements, SchemaFetchFlags fetchFlags, Hashtable properties) at ai.a(Boolean A_0, Hashtable A_1) at ai.a(Object A_0, a5 A_1) at ab.a4(Object A_0, EventArgs A_1) at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e) at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e) at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e) at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met) at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ToolStrip.WndProc(Message& m) at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) -----[InnerException]-------------------- at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal) at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info) at System.String.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at SD.LLBLGen.Pro.DBDrivers.SybaseAse.SybaseAseSchemaRetriever.PopulateAllStoredProcedureParameters(AseConnection openSybaseAseConnection)

SD.LLBLGen.Pro.DBDrivers.SybaseAseDBDriver mscorlib

scale is NULL there, so it shouldn't end up in that if branch... Here, at varchar parameters it indeed doesn't as scale is NULL and the string representation (it's read from a datatable) is an empty string in that case... Will see if I can add some other code there to work around this weird issue...

Do You think you'll find time today ? that would be great

erl wrote:

Do You think you'll find time today ? that would be great

Yes. I've changed the code to use int.TryParse instead. That should be 100% robust now . I have no idea what Sybase returns for the NULL in scale, but apparently it's not DBNull.Value or anything similar. The weird thing is that here it DOES return DBNull.Value for NULL.

Anyway, please check the attached driver. If this still gives an error, I've no idea what else to try.

No More Exception on my Sybase v15 BUT now when I select a proc. that has underscore in its name more than one are proposed in the "New Stored Procedures found" window (takes underscore has wildcard) see attachement .

The generated code looks good Progress has been made !

erl wrote:

No More Exception on my Sybase v15 BUT now when I select a proc. that has underscore in its name more than one are proposed in the "New Stored Procedures found" window (takes underscore has wildcard) see attachement . The generated code looks good Progress has been made !

Isn't this what should be happening as there are 2 different procedures? Or do you mean: if I pick ps_aa_test, I get the other one (psaatest) as well ?

Yes that what I meant

More info : on Sybase V12 I could select 50 procedures with at least one underscore in their name without problem but only few were proposed when I wanted to add them to "retrieval stored procedure Calls" node, the others were proposed only for Action Stored procedure.

And BTW parameter direction could be fixed now we've got _sp_sproc_columns _ that could help.

Back on my Sybase v15 I can only add my procedure in the "retrieval stored procedure Calls" node.(they are not proposed for "Action stored procedure Calls" this is the opposite of v12 case above)

Could it be something in the project properties ?

erl wrote:

Yes that what I meant

Ok, though all non-checked procs are tossed out before schema info is retrieved. (case sensitive routine in the driver, no wildcards). I'll see I can repro this.

More info : on Sybase V12 I could select 50 procedures with at least one underscore in their name without problem but only few were proposed when I wanted to add them to "retrieval stored procedure Calls" node, the others were proposed only for Action Stored procedure.

A proc which is reported by sybase to have no resultset is specified as an action proc. If this isn't the case, the proc has to be set manually to have a resultset in the catalog explorer (browse to the proc, right click #0 -> change -> set it to 1 -> it's a retrieval proc)

And BTW parameter direction could be fixed now we've got _sp_sproc_columns _ that could help.

It sets parameter direction on versions 15000 (version reported by sybase) or higher. 12500 doesn't have the column, but a patch version of 12.5 does? (12.5.2 ? )

Back on my Sybase v15 I can only add my procedure in the "retrieval stored procedure Calls" node.(they are not proposed for "Action stored procedure Calls" this is the opposite of v12 case above) Could it be something in the project properties ?

No, it's what sybase reports. We use the SET FMTONLY ON trick for that, similar to sqlserver. SET FMTONLY ON; exec proc; SET FMTONLY OFF. The # of returned empty datatables is the # of resultsets. To my knowledge we couldn't find a meta-data element in sybase which reported the # of resultsets in procs.

I get it on V15 changing the resultset works fine.

On V12 I have to manage the number of resultset myself it's ok.

about parameter direction, I guess my v12 has been patched because the result of a call sp_sproc_columns ps_mx000_add_stock returns the column called "mode" with the correct direction see attachement .

thanks

erl wrote:

I get it on V15 changing the resultset value works fine.

On V12 I have to manage the number of resultset myself it's ok.

about parameter direction, I guess my v12 has been patched because the result of a call sp_sproc_columns ps_mx000_add_stock returns the column called "mode" with the correct direction see attachement .

thanks

with the attachement

Weird isn't it? Sybase makes no mention of it. (but as you already have pointed out with the parameter direction info in another thread, they aren't worlds greatest documentation writers) Checking: http://infocenter.sybase.com/help/topic/com.sybase.dc00212_1254/html/nfg1254/CHDFADAF.htm

I see no mentioning about any addition of this column. If I check the docs on sp_sproc_column for v12.5.1: http://infocenter.sybase.com/help/topic/com.sybase.dc36273_1251/html/sprocs/X46574.htm

there's no mode column anywhere in the docs for v12.5.*. Yet you get the mode column... . Why doesn't sybase document their stuff better... We followed the documentation provided by Sybase, so we couldn't do anything else but go for the choice of 'the info isnt' there'.

I'm not sure if we can assume 'mode' is there though... I can add a couple of lines which check whether 'mode' is a valid column in the resultset...

I've changed the code a bit which now tests for a column 'mode' instead of relying on the version reported. So a patched v12.5 version which has this undocumented mode column can use it too

See attached driver.

Hi,

I've just tested the last driver you sent. On (my) Sybase V12.5 procedures parameter direction are perfectly retrieved. (tried on more than 50 stored procedures)

so now on sybase 12.5 /15 we've got procedures parameter direction managed / procedure name (with underscore) doesn't bother us anymore. good job !

proposal: a stored proc. multi selection in oder to change the result set value would be great (may be in the next version 2.6) but we can live without.

I'm pretty satisfied now on Sybase !

Thanks

Thanks for testing

The multi-select for resultsetvalue is build in actually, it's enabled for sqlserver at the moment, we can enable it for sybase as well. It does require changes in multiple drivers (as an enum value has to be changed) and the designer core functionality assembly so that's indeed something we'll consider for v2.6 (as it's a minor change overall)