Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / SQL Server / ADP / February 2006

Tip: Looking for answers? Try searching our database.

Parameterized queries

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Chris - 16 Feb 2006 15:01 GMT
Hi, I am using ADO against an Sql Server 2000 backend. My problem is
I'm trying to use a dynamic sql query as part of an import csv process.
The final stage after matching field names, etc is to build a
parameterized query.

Unfortunatly when it comes to executing the command all I get is the
error "Must declare the variable @name". From what I could find it
seems that ADO will not support parameterized queries.

Could anyone please advise if the know of a way to get this to work
with ADO or an alternative.

Thanks, Chris.
Sylvain Lafontaine - 16 Feb 2006 15:50 GMT
Maybe a little piece of code of what you have tried to do will help us in
assisting you.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> Hi, I am using ADO against an Sql Server 2000 backend. My problem is
> I'm trying to use a dynamic sql query as part of an import csv process.
[quoted text clipped - 9 lines]
>
> Thanks, Chris.
Chris - 17 Feb 2006 10:05 GMT
Here is the code I wanted to run, to solve the problem I've had to
write a stored procedure which seems to work.
But this has the disadvantage that I need a stored procedure for every
table I want to be able to import into, instead of being able to use a
generic method that matches fields from the csv file to the sql table.

   '''''''''''''''''''''''''
   ''' Create parameters
   ''' and SQL
   '''''''''''''''''''''''''
   For index = 0 To field_count
       Set cmd_params(index) = Nothing
   Next

   For index = LBound(matched_field_indices) To
UBound(matched_field_indices)
       Set param = insert_cmd.CreateParameter( _
           name:="@" & target_fields(index), _
           Direction:=adParamInput, _
           Type:=adVarChar, _
           Size:=8000)
       insert_cmd.Parameters.Append param

       Let sql_fields = sql_fields & "," & target_fields(index)
       Let sql_params = sql_params & "," & param.name

       Set cmd_params(matched_field_indices(index)) = param
   Next
   'Trim leading ,
   Let sql_fields = Mid(sql_fields, 2)
   Let sql_params = Mid(sql_params, 2)

   Let sql = "INSERT INTO " & target_table & " (" & sql_fields & ")
VALUES (" & sql_params & ")"
   Set insert_cmd.ActiveConnection = target_conn
   Let insert_cmd.CommandText = sql
   Let insert_cmd.CommandType = adCmdText

   rs.MoveNext
   While Not rs.EOF
       For index = 0 To field_count
           If Not cmd_params(index) Is Nothing Then
               cmd_params(index) = rs(index).value
           End If
       Next
       insert_cmd.Execute options:=adExecuteNoRecords
       rs.MoveNext
   Wend
   rs.Close
Sylvain Lafontaine - 17 Feb 2006 18:02 GMT
Usually, named parameters are for stored procedures.  With ODBC, it was
possible to use unnamed parameters but it's the first time that I see
someone trying to use named parameters with a SQL-String and ADO.

I will make some tests tonight but in the meantime, I would suggest that you
drop the use of parameters if you want to dynamically build your SQL Insert
Statement.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> Here is the code I wanted to run, to solve the problem I've had to
> write a stored procedure which seems to work.
[quoted text clipped - 45 lines]
>    Wend
>    rs.Close
Chris - 18 Feb 2006 22:00 GMT
That's one option but does that not then raise the issue of sql
injection attacks? Hence why I turned it into a stored procedure.
Sylvain Lafontaine - 18 Feb 2006 22:31 GMT
Yes, preventing injection attacks is another reason why to replace your
INSERT INTO sql statement with a stored procedure.  (I forgot to mention
that with ADO.NET, it is now possible to named parameters not only for
stored procedures but also for regular sql strings.)

However, if you want a trully secure system, don't forget then even when the
values has been stored inside the database, there is still the possibility
of having injection everywhere you will build a dynamic sql string; even if
you are using values from a table field.

Signature

Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF

> That's one option but does that not then raise the issue of sql
> injection attacks? Hence why I turned it into a stored procedure.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.