Re: Insert Date and Time in SQL Server 2000 using ASP

From: Mark Schupp (nospan_at_nospam.com)
Date: 02/28/05 

Date: Mon, 28 Feb 2005 14:19:03 -0800

> What is the basis of your refusal to use stored procedures? Do you have
> applications that actively communicate with SQL Server, Access and Oracle
> simultaneously? Even if that's the case, doesn't it make more sense to
> encapsulate the provider-specific code within each database, than to store
> all those ad hoc queries (likely with provider-specific extensions anyway)
> in your application code?

Call it laziness if you must (I prefer to call it "refusal to deal with
Oracle any more than necessary") but we have a single application that works
unchanged against Access, Oracle, and SQLServer (there is automated logic in
the "statement building" process to deal with the different SQL dialects).
The effort to code the SQL logic into 3 separate sets of stored procedures
(and modify them for upgrades) is more than I am willing to accept at this
point in time.

Although I believe we are creating the SQL statements safely I am concerned
about SQL Injection and am considering gradually migrating to parameterized
command objects for future upgrades so I was wondering if there were any
performance "gotchas". 

-- 
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com
"Aaron [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:ertPradHFHA.3628@TK2MSFTNGP15.phx.gbl...
> > on a related topic I often see the recommendation to use a command
object
> > and parameters instead of dynamic SQL (so far I refuse to write stored
> > procedures for SQL Server, Access, AND Oracle).
>
> The preferred order, in general, is:
>
> - stored procedure with command object
> - stored procedure with connection object
> - dynamic SQL
>
> I usually bypass #1 in favor of #2, because I find the syntax much more
> intuitive, and debugging easier.  I usually only use #1 if I require
access
> to output/return values.  If there were other items I could inject between
> #2 and #3, I would.
>
> What is the basis of your refusal to use stored procedures?  Do you have
> applications that actively communicate with SQL Server, Access and Oracle
> simultaneously?  Even if that's the case, doesn't it make more sense to
> encapsulate the provider-specific code within each database, than to store
> all those ad hoc queries (likely with provider-specific extensions anyway)
> in your application code?
>
> A
>
>

Relevant Pages

  • Re: How to convince my customer to use SQL2005 instaed of Oracle10g
    ... migration to Sql 2005 would be direct & straight forward, quick, and ... If I were you I would focus one SQL Server 2005 clearest advantages ... would need a 4 processor license but for Oracle you would need a 16 ... You mentioned Availability, so I assume your looking into HA (high ...
    (microsoft.public.sqlserver)
  • Re: SQL Server 2005 vs Oracle
    ... SQL and Oracle. ... SQL Server one sizes log files to handle the largest transaction and its ...
    (comp.databases.ms-sqlserver)
  • Re: IOT, memory and transaction time
    ... What is a better way of structuring this SQL for Oracle? ... Oracle expertise available at the moment but certainly SQL Server ... Server uses dynamic memory allocation whereas Oracle, in our tests, ...
    (comp.databases.oracle.misc)
  • Re: How to convince my customer to use SQL2005 instaed of Oracle10g
    ... the old Sql versus Oracle debate. ... If I were you I would focus one SQL Server 2005 clearest advantages ... You mentioned Availability, so I assume your looking into HA (high ...
    (microsoft.public.sqlserver)
  • Re: SQL -> Oracle
    ... > 2- extracted all my SQL queries in one single file (that was the tedious ... > 3- now whenever I need new query. ... > - Sybase and SQL server prefix their parameters with '@' ... > - Firebird and Oracle have selectable stored procedures so you use them ...
    (borland.public.delphi.non-technical)