-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error calling stored procedure with many parameters. [BUG] #326
Comments
Hi @snotmare , Could you post the snippet of code that generates the error? Just the Or, if you are using the |
Good morning @markdirish ! This is the portion of code that makes the stored procedure call...
|
Ok, I created a large procedure with 80 INOUT parameters, and it seemed to behave ok. So it shouldn't be the parameter count itself. Next thing lets try, lets get a unixODBC trace (this has slightly different information than the cwb trace, which is an IBM i-specific trace). Instructions on getting a unixODBC trace can be found here: https://github.com/markdirish/node-odbc#debugging |
*** UPDATE *** Please ignore the following post. It contains invalid information due to a faulty test on my part. Hello! I ran my stored procedure test today to build the trace you asked for and... it works now for some reason. Relatable meme I don't have an explanation of why it's working now. I'm running the same code I did last Wednesday. I have installed some python packages on my pc for an unrelated project, but I don't see how that would impact anything. Our system admin says nothing on our test lpar has changed, but, "it would have IPL'd on last Friday and likely cleaned up the SQLPKG as part of that IPL" In case it helps, I've attached the unix trace you asked for plus a new odbc trace. I'll do some more testing over the next week or so and let you know if I run into this again. As always, thanks for your help! |
Neither the SQL.LOG or latest cwbtrace have any relevant calls in them. It connects to the database and calls SQLGetInfo, but that's it. There's no calls to prepare, or SQLProcedures like in the original cwbtrace. I can say that the HY090 is caused by an error when checking for wildcards in the schema / procedure names. Unfortunately, the driver doesn't trace out the parameters, but I think SQL.log should show us what was being passed. |
Ugh, thank you. My prior test was invalid. I have run this again with the trace you asked for and I ran into the issue as expected. Sorry for the confusion. |
Hi there, After testing many, many things I found out it it is the length of the output parameter. What I do is:
This works fine when I call it this way: When I enhance the OUT Parameter to (for example) 16000 it doesn't work anymore. Many thanks and have a great weekend! |
Sitting here a few weeks later, and I think I know the issue... Is Try replacing |
Good morning! I gave that a shot but ran into this error...
This is how I updated the code to test that out...
As you can see, I also wrote the parameters to the console...
This is the call I'm expecting it to make... Thank you for your help! As a side note, could the error message indicate how many parameters are expected and how many were passed in? Ben |
Ok, one more SQL.log with the new code and it should show me the number of params it expects. Delete your old log before running or else it will append to that file |
No problem. Here you go! |
Well, I forgot that ODBC uses How about this. Run the following query, and let me know the result:
If you have more than one procedure with that name, you may have to add another part of the |
Yep, I had to add the schema to the where clause. I see 75 columns. |
And it looks like you are passing in 75 values. Not sure why it thinks there is a mistmatch. How about a cwb trace, maybe that will tell us a little more? Or, if you have installed tools that can recompile the package, you can add the following line in
Once you've added that line, you can run |
This is the trace I captured. I killed it after about 30 mins because it looked like it hung. Hopefully this contains the info you're looking for. We don't code in c++, but it looks like there are some vscode tools I can use. I'll see if I can debug or something to get that count. |
node-odbc Version: 2.4.7 I ran into a similar issue with After doing some digging, I found that this error was caused by having a different
Changing the |
@myronng Thanks for the tip. In my case, the proc name and specific name already match :/. That table does indicate the number of input, output, and inout params. In my case, input is 72, inout is 3 for the total of 75 mentioned above. |
@markdirish Hello! I've poked around a bit to see if I can recompile the c++ binaries like you suggested (#326 (comment)). I'm not a c++ dev and haven't had any luck with that :/. Sorry to be a pain, but would it be possible for you to create that change in a branch? I can install from that branch and test it out again. |
Hi @snotmare , I now have a branch called https://github.com/markdirish/node-odbc/tree/print-param-count |
Thanks for doing that @markdirish ! I pulled that branch and reran the code with a trace. I've attached both types of traces. |
Oh sorry for the confusion, I'm just interested in what it should spit out to the console. It should just print stuff out when you run |
@markdirish Ah, gotcha. Here is what is coming from my console... [
Caused By: Error: [odbc] The number of parameters the procedure expects and and the number of passed parameters is not equal |
@snotmare you may need to recompile the program after you pulled down the branch:
What I am expecting in the output is two lines that look like:
You can check that they should fire (and that you have the right code) by looking in the If you try to build and it complains that you don't have the proper build tools, I can try to make you a prebuilt binary in a few hours when I get to a Windows system that has that all set up |
@markdirish Man, I'm just not being very helpful, am I? Sorry about that. Here is the long-awaited info you are looking for! The number of columns is 420 |
Good morning! Any luck on tracking down this issue? |
Hi @snotmare , So I did track down what might be the issue. When I have two procedures named MIRISH.MYPROC:
When I use this When I call with values HOWEVER, I'm not even sure if this is your issue. In this reply #326 (comment), you said that it returned 75 for you. But somewhere it seems like it is finding additional columns for your In my case, it clearly is pulling off the procedure name, not the specific procedure name. I am going to discuss with @kadler what to do about it. I don't think I can just drop the check, as I need information about the columns to bind. In the case where it is returning more columns than it expects, there isn't a good programmatic way for me to grab the correct ones. In the meantime, I think the only workaround is to ensure that all of your procedures have unique names. |
@markdirish Based on what you found, I did some playing and found that if I specify the schema in my call, I can get this to work!
Running this SQL...
...gives me 75 columns. Running this...
...gives me 420. This is because we have our prod version of the code running in DUNC while we have other versions of the code being tested in other schemas/libraries. So, good news that we can get this to work. However, this will still be an issue for us because we don't want to hard code the schema in our procedure call. We would like to allow the system to find the correct procedure based on our library list. That way we can change the library list to include one of our test libraries and have our node code hit the test procedure. Can you change the internal code to find the number of columns while accounting for the correct schema? I'm also curious, do you have to query for sysprocedurecols every time we make a call, or is that information cached? |
Hello! Thought I'd check in on this issue. Any luck resolving it? Thanks |
@snotmare I doubt your issue with a procedure being found in multiple schemas will be resolved in node-odbc. Instead I think you will have to run a query prior to calling the stored procedure to find the schema to use, that's what I decided to do in our project. You can get the routine_schema column from qsys2.sysprocs - join against qsys2.library_list_info and filter by parameter count then order by ordinal position. |
@markdirish @kadler I have an idea to handle multiple procedures in the same schema - SQLProcedureColumns() also returns the ordinal position column which could be used to find the boundary between different versions of a procedure and select the right set of parameters. |
@brandonp42 Hello! Has there been any progress on this issue? |
Hi @snotmare, last I heard @markdirish and @kadler didn't like my proposal. Mark submitted a PR with an alternate fix a couple months ago which hasn't been merged yet. I don't know if they are still planning to work on that further or what's going on. |
Describe your system
odbc Package Version: 2.4.7
ODBC Driver: IBM i Access ODBC Driver
Database Name: DB2
Database Version: Latest version + patches
Database OS: Power i
Node.js Version: 14.17.3
Node.js OS: Windows
Hello! I'm testing out odbc with our existing code and ran into an issue calling a stored procedure. Here's the call (lots of parameters)...
call WOR3070SP(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
This is the error...
Code: 30038, State: HY090, Message: [IBM][System i Access ODBC Driver]Invalid string or buffer length.
Our server admin says he does not see the stored procedure call on the database side, so I'm assuming there's something in the odbc module or the driver that's keeping this from working.
I've also attached an odbc trace.
cwbtrace-64-node.exe-28460.log
Let me know if there is any more information I can provide. Thanks again for your help!
The text was updated successfully, but these errors were encountered: