Delete Query ?

>> Does the OP want portability? Why spend extra effort in coding for someth
ing that may never be required (ever), lets face it an extremely small propo
rtion of dev's need SQL portability. <<
I totally disagree with that last statement, based on 35 years in the
trade. Proprietary code bites you in ass from product to product and
even from release to release of the same product. To think that
writing Standard SQL is an "extra effort" is simply wrong. Even for
good programmers, trying to remember a dozen different syntaxes is more
effort than to use the real language.
Run the code; read the standards.
I also used a fixed length CHAR(n) column because the fixed length is a
good check on the data element that can put into a regular expression
and make maintaining the table easier. VARCHAR(n) can save storage,
but at the expense of access time and indexing.> I totally disagree with that last statement, based on 35 years in the
> trade. Proprietary code bites you in ass from product to product and
> even from release to release of the same product. To think that
> writing Standard SQL is an "extra effort" is simply wrong. Even for
> good programmers, trying to remember a dozen different syntaxes is more
> effort than to use the real language.
35 years, 20 years makes no difference, its what you have done in that time,
for the past 20 years i've been cutting code using a number of different
databases and languages so i can speak from developer experience - can you
(really) or is it just SQL?
Propritary code does not bite you in the ass, standard SQL is a myth, it
behaves different between products anyway - locking behaviour, query
behaviour etc...
Tools between products are different as well, the way products work etc...
Writing standard code involves significantly more effort, you need to test
for each platform you tell your customers you support - is that effort
really worth it? There are only a few companies that think so.
Good programmers know to take advantage of the tools that are in front of
them to get the most efficient business solution for the business problem
they are coding for, they do not indulge themselves in IT solutions for the
sake of a long lost and forgotten portability standard.
Products are diverging release by release.

> I also used a fixed length CHAR(n) column because the fixed length is a
> good check on the data element that can put into a regular expression
> and make maintaining the table easier. VARCHAR(n) can save storage,
> but at the expense of access time and indexing.
That is just complete rubbish - check the product specs as you put it, using
varchar is not at the expense of access time nor indexing, in fact its
better because the data is on less pages so you need less IO's, less locking
etc...
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1132863499.248876.91150@.g44g2000cwa.googlegroups.com...
> I totally disagree with that last statement, based on 35 years in the
> trade. Proprietary code bites you in ass from product to product and
> even from release to release of the same product. To think that
> writing Standard SQL is an "extra effort" is simply wrong. Even for
> good programmers, trying to remember a dozen different syntaxes is more
> effort than to use the real language.
>
> Run the code; read the standards.
> I also used a fixed length CHAR(n) column because the fixed length is a
> good check on the data element that can put into a regular expression
> and make maintaining the table easier. VARCHAR(n) can save storage,
> but at the expense of access time and indexing.
>