Hi Chris:
I believe I'm OK security wise as the string is created in a data
translation layer that converts a persistable object to a Sql string.
The Sql string represents a parameterized call to a stored procedure and is
passed to a Sql command object.
The big drawback to this approach is no access to output parameters.
There are a few advantages, however:
1)It is easy to debug as I can cut and paste the resultant string into
query analyzer.
2)There is much less dependency on the data access technology. It was
relatively trivial to convert my ADO code to ADO.NET.
3)My data access layer can be very simple.
All calls to the data access layer from the data translation layer look
like this:
return SqlService.ExecutePersist(sqlString,logon);
All data retrievals look like this:
return SqlService.Fetch(sqlString,tableName,logon);
I suppose it is a whole other topic, but I decided to use a limited subset
of the functionality available in ADO.NET. For example, I unpack datasets
into collections of objects, rather than have the client app interact
directly with the dataset.
thanks, Greg
On Fri, 3 May 2002 01:45:14 +0100, Chris Anderson <[EMAIL PROTECTED]>
wrote:
>Performance-wise (and security-wise wrt possible sql-injecting hacks) I
>would use a SQLCommand object and a parameterised query rather than a
>direct SQL string (therefore removing the requirement for this type of
>function)
>
>Merak
>
>> I have the following helper method to format sql string parameters:
>>
>> public static string DoQuotes(string sqlParam)
>> {
>> if (sqlParam.IndexOf("'") > 0)
>> {
>> sqlParam = sqlParam.Replace("'","''");
>> }
>>
>> return "'" + sqlParam + "'";
>> }
>>
>>
>> Is there a better way, performance-wise?
>>
>> thanks, Greg
>
>You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
>subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
