Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I can see two differences between your example code and your own <code>insertSQL()</code> implementation that might make a difference.</p> <p>First, the example code calls a different method than your implementation of <code>insertSQL()</code>. It calls <code>ExecuteNonSelectSQL()</code> and your code calls <code>ExecuteSelectSQL()</code>. Just based on the name, I'd guess one is intended to return a result set and the other is not. I don't know if that would affect the execution of your <code>INSERT</code> statement, or not, but it might be worth investigating.</p> <p>Second, the parameter names in the SQL statements are different. If your data-tier code is referring to parameters by name, it seems reasonable that it might also expect a certain naming convention for those parameters.</p> <p>Your sample code uses the singular form of the word "parameter", e.g. <code>@Parameter0</code>, as below:</p> <pre><code>ssql = "INSERT INTO [ServiceStation].[dbo].[OnBaseSweepFaxPath] ([FaxLine],[FaxSweepPath] ,[FaxBackupPath])" ssql += "VALUES(@Parameter0, @Parameter1, @Parameter2)" </code></pre> <p>While your code used the plural form of the word "parameter", e.g. <code>@parameters0</code> (note the extra 's') as below:</p> <pre><code>sSql = "INSERT INTO [ServiceStation].[dbo].[ProcessLayout] ([ProcessName], [ProcessingLevel], [Department], [FormName]) VALUES (@parameters0, @parameters1, @parameters2, @parameters3)"; </code></pre> <p>If your data-tier is generating parameter names based on the number of elements in the <code>parameters</code> array, then if might include code like this:</p> <pre><code>string ParameterName; for (int i = 0; i &lt; parameters.Length; i++) { ParameterName = "@Parameter" + i.ToString(); //... command.Parameters[ParameterName].Value = parameters[0]; //... } </code></pre> <p>Which would fail because the SQL statement you passed to it says the name should be <code>@parameters0</code> instead of <code>@Parameter0</code> which is what it's trying to use. See the sample code on <a href="http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.parameters.aspx" rel="nofollow">this MSDN page</a> for more information on how the parameters named in the text of the SQL statement may be referred to in code.</p> <p>Of course I have no idea if that's how your data-tier is implemented, but it's a difference that's easy enough to test. Just change the text of your <code>VALUES</code> clause to match parameter names used in your example, like so:</p> <pre><code>sSql = "INSERT INTO [ServiceStation].[dbo].[ProcessLayout] ([ProcessName], [ProcessingLevel], [Department], [FormName]) VALUES (@Parameter0, @Parameter1, @Parameter2, @Parameter3)"; </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload