We have some code that call a SQL Stored Procedure from NAV and on some machines the NAV Code errors with the following message:
It is not possible to assign a _Parameter to a Parameter
The exact same code executes without issues on other machines, i suspect that this could be a build issue in NAV 2009 SP1 as there are a number of different builds in use and I was wondering if anyone else has experienced this? I don’t wnat to tell teh customer to change the build thay are using unless i really have too!
The main part of the code is as follows:
ac := DBC;
DBCC.ActiveConnection := ac;
DBCC.CommandType := 4;
DBCC.CommandText := SPName;
DBCC.CommandTimeout := 0;
IF NoParameters > 0 THEN BEGIN
i += 1;
DBCP := DBCC.CreateParameter(ParameterName[i],200,1,1024,ParameterValue[i]);
UNTIL i = NoParameters;
The bold line is where the debugger breaks.
Any help with this would be greatly appreciated.
I checked our database and do not find any report of this type of issue, but it is possible there was a platform fix that I just am not seeing or possibly corrected with a different type of error message. In general though, it is not a good idea to run different versions of the platform code on different machines. In fact on a hotfix build (can’t remember if SP1 or R2) we have put a check in to not allow for different builds. You must now have all clients/service tiers/NAS on the same build or you will recieve an error. It is also recommended (sometimes it is mandatory or you will get an error) to compile all objects after updating to a new build. It is due to compiler changes/fixes across build numbers. I just mention this since I believe it would be a good idea to udate to R2 build for this type of case and it would probably fix the issue based on what you are saying, unless it is pure envirnonmental issue, but that would be a reach I think. Updating to R2 as you probably know takes a few additinal steps beyond just copying/pasting the files. It is easiest to unisntall/reintall to get to R2 due to the changes made in the folder structures and the placement of certain files. After the resinstall, compile all objects and check that no new compiler rules are broken by customizations or Add On products. Maybe someone on the community will have a better/quicker solution, but I just wanted to mention the fact that mixed versions is not a great idea any longer, unlike earlier versions where it wasn’t nearly as important.
Hi, I would agree with Nick on this one. If you keep everything on the same build, it would probably eliminate some of the most vexing issues now and in the future. I’m also sure once you explain the benefits of being on the same build, the client will be on board with it as well. Good luck!
I have same issue but this happen when I modify CU in a DB on other PC and restore it on production server.
Do you solved the problem?