Labview and SQL stored procedure

[SeeSharpDev]

I have a stored procedure looking like this:

CREATE PROCEDURE [dbo].[StoreTemp]
(@Temperature float,
@Seconds int,
@SessionId int)
AS
BEGIN
DECLARE @Unit varchar(20);

SELECT @Unit = RecordingUnit FROM ReadLastUnit;

INSERT INTO DATASET (Temperature_C, Temperature_F, Seconds, SessionId, [Time])
SELECT
CASE WHEN @Unit = 'Celsius' THEN @Temperature ELSE NULL END,
CASE WHEN @Unit != 'Celsius' THEN @Temperature ELSE NULL END,
@Seconds, @SessionId, GETDATE();
END

In labview I prepare the string with parameters like

execute StoreTemp %2.1f, %d, %d

which takes 3 parameters which are input through a "Format into string" box.

The following error is thrown:

> Error -2147217900 occurred at Exception occurred in Microsoft OLE DB Provider for ODBC Drivers:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Procedure or function StoreTemp has too many arguments specified. in ADODBCommand

The above SQL Server stored procedure should basically get the one measurement value `@Temperature` from LabView, and depending on the recording settings (- which is read as @Unit from ReadLastUnit View) either store the temperature in one unit and fill the other unit column with null, and vice versa. Somehow it seems to be getting more parameters, although 3 inputs are specified and 3 parameters are passed through LabView. What does this error mean then?

SQLToolkit is used for connection by the way.

[SeeSharpDev · Accepted solution]

Also, in general I am able to read from the database using SQLToolkit. Only writing to the database using stored procedures fails. For another SubVI I am writing the full insert string which works, but otherwise have the same issue with using the stored procedure dedicated for that SubVI. For this one I have to use stored procedure, as there are case statements inside it which you can see that dictates which column to store the temperature data into.

EDIT: Solved it, changed the SQL stored procedure instead by recieving the SessionId from the primary key table instead of reading it from database in Labview

[Yamaeda]

Nice solution. It's always smarter to let the DB do as much work as possible internally instead of reading just so you can write. 🙂