>Dmitry, rather than concatenating values, use parameterized SQL.
>

tDatetime=datetime()
>lcSQL="update MyTable Set DateTimeColumn = ?tdatetime where Pk = ?nPk"
>

>
>Apart from taking care of the conversions for you, in SQL Server 7 and later a parameterized query like this will be cached at the server, giving significant improvement benefits.
>
>The other advantage is that parameters prevent SQL Injection. The concatenated examples in this thread are all wide open to injection if a hacker can sneak a quote character into the parameter followed by their own SQL command that could be a SELECT * to steal your customer list or a DROP if they are malicious. You can write code to watch for quotes and other injection attempts, but using parameters makes it a complete non-event.
>
>FWIW for those who have not encountered SQL Injection, here's a simple example of concatenated SQL:
>

"SELECT * FROM members WHERE username = "'+lcusername+"'"

>If the hacker can enter their username as bob'; DROP table members; -- then the SQL becomes
>

SELECT * FROM members WHERE username='bob'; DROP table members; --'

>and you get the idea. yes you can write code to prevent use of quote characters etc but this cannot occur at all if you use parameters.

John, thank you for the warning of SQL Injection and for illustrating the case. In this particular case, for which I asked the question, there is no danger of injection since the SQL command is created in code by the application and not taking user entry into account.

But, having said it, I am not sure, in general how I can use the parametrized command with Cursor Adapter approach. For example, say I have a user entry form where Cursor Adapter is created, fills cursor with data from the back end (SQL Server). Then, when user makes changes, the program simply executes TableUpdate() which updates the table in the SQL Server. Could someone enter the "malicious" entry (similar to your example) in one of the fields and cause the table dropped or something like this on TableUpdate()?