Last post Apr 26, 2005 02:30 PM by gatorspike
Apr 07, 2005 11:23 AM|softy|LINK
I have code that works fine using apliccation block ver 1 but not working good with the new version.
I have sp that have several parameters with null as default.
arParms(1).Value = 1
The sp has more then 1 parameters but when i put null as the default value in the sp it should ignore those parameters.
when i run it return this error:
The number of parameters does not match number of values for stored procedure.
it seems to be a bug because it should work.
Dows somebody knows what i should do or i should stay with the old version
Apr 13, 2005 08:08 AM|gatorspike|LINK
Can we see your sp definition?
Apr 18, 2005 04:41 PM|Robbo|LINK
Help! I'm running into the same problem with this code. It looks like the application block ends up with 2 copies of the parameters for some reason:
SET NOCOUNT ON
PERSON.person_id = @person_id
CommandWrapper.Command.Connection = Db.GetConnection()
Apr 20, 2005 12:05 PM|gatorspike|LINK
Clear the cache for the app block. Then try again.
Apr 25, 2005 03:02 PM|Robbo|LINK
Nada, makes no difference.
The call to LoadDataSet() ends up in DoIsFurtherPreparationNeeded() which returns true because needsParameters is set to True. So in Database.cs line 992 parameterCache.FillParameters(command, ParameterToken); gets called again and I get a duplicate set
of params. Haven't tracked down exactly why it first thinks there are no parameters supplied then later gets duplicates but its looking quite a bit like a bug so far.
Apr 25, 2005 03:42 PM|gatorspike|LINK
Sorry, I really did not look very well last time. I jumped to conclusions based on a bug with the first data block.
It appears that the line:
Simply goes to the database and retrieves all of the parameters for the sproc. So it kinda makes sense that you would see another copy. I would think that the first set would get removed though. Have you tried destroying the first copy? At any rate you
will still need to set the value of the parameter at index 0; If you still get nowhere reply and I will write my own test case.
Apr 25, 2005 04:35 PM|Robbo|LINK
Let me fill you in on what I'm trying to do. The DAAB version 2.0 had a SQLParameterCache that we used quite a bit to auto retrieve the sp params and cache them for subsequent calls. This way we didn't have to hardcode the parameters and had more flexible
code as a result. I'm trying to us the ParameterCache in this version of the block to do the same thing ie. Prepare the command by finding the stored proc params on its own, then simply executing the command. I'm stuck with this problem. Am I not understanding
the function of the ParameterCache?
Apr 26, 2005 11:44 AM|gatorspike|LINK
I stepped through the block using your code (I used a Northwind sproc) and got the same exact results as you. It is adding the parameters twice resulting in four parms. Once when you add them and again when it checks to see if the stuff
is cached already. It should see that you have them. The bug is in Db.LoadDataSet((CommandWrapper2, dset2, tablename). Replace that call with the following one and it should work.
dset = Db.ExecuteDataSet(CommandWrapper)
Also, you do not need to call FillParameters.
Here is my method:
Dim dset2 As DataSet
CommandWrapper2.Command.Connection = Db.GetConnection()
' this works
Db.LoadDataSet(CommandWrapper2, dset2, tablename)
Apr 26, 2005 12:28 PM|Robbo|LINK
Thanks for digging up the bug Mike. Any ETA on an official fix for this problem? ExecuteDataSet() is good but I use strongly-typed datasets all over the place so LoadDataSet() is my preferred method of filling. Otherwise I'll need to merge and take a
Apr 26, 2005 02:30 PM|gatorspike|LINK
You are welcome. I have no idea when or if they will fix it. You can however go to the Enterprise Library home on GotDotNet.com at
http://www.gotdotnet.com/workspaces/workspace.aspx?id=295a464a-6072-4e25-94e2-91be63527327. There may be an update posted there. You will probably find others there that are much more capable than I with regard to the Library.