Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Manifest constant substitution (and header files)

4 posts in Product Futures Discussion Last posting was on 2003-07-24 12:32:07.0Z
Frank_Hamersley Posted on 2003-07-23 08:38:45.0Z
From: "Frank_Hamersley" <terabite@bigpond.com>
Subject: Manifest constant substitution (and header files)
Date: Wed, 23 Jul 2003 18:38:45 +1000
Lines: 52
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Message-ID: <ObpteZPUDHA.346@forums-2-dub>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: ESS-p-144-138-7-32.mega.tmns.net.au 144.138.7.32
Path: forums-1-dub!forums-master.sybase.com!forums-2-dub.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:1314
Article PK: 95553

One thing that always bugs me about SQL is the lack of an inherent mechanism
for compile time substitution of manifest constants.

This is probably viewed as unfashionable in the 21st century but in times
past (particularly with assembler) it greatly reduced the risk of latent
bugs when code was being revised at a later date, but allows for use of
constants (over variables) to improve execution times.

This need just arose yet again as I was doing a code walk through on an
infrequently executed sproc and discovered the coder had forgotten to add an
extra constant to an IN clause like...

obj_id IN (2000,2001,2002)

This was due to the original work of adding new cases 2001 and 2002 being
followed up a month later with the 3rd (overlooked) case and the scan of the
code base not catching the coders eye. It should have read ...

obj_id IN (2000,2001,2002,2003)

I know this can be done in a few lines of perl and ensure that it always
gets resolved by using makefiles to parse/compile modified stored proc
scripts into the target server, but I think the keeping it all in the family
is desirable. Obviously you could build a better schema that had it all in
tables, but there are always oversights/unforeseen requirements changes (and
time pressure) that prevents the building of that bit more structure that
makes it perfect being table driven ;-).

I could reserve a range of numbers so maintenance demands on a BETWEEN
clause are reduced, but constructs like below are much more elegant in
protecting against future changes without adding excess or arbitrary ranges.

/home/code/defines.sql
%DEFINE %OBJ_LOWER% 2000
%DEFINE %OBJ_UPPER% 2004

and

/home/code/sproc.sql
%INCLUDE /home/code/defines.sql
.....
obj_id BETWEEN %OBJ_LOWER% AND %OBJ_UPPER%

Clearly extensions like this will affect portability, but if you have
developed a system in Sybase, there is no reason why isql could not have a
switch to write out the post processed text for extradition to elsewhere!

Cheers,

Frank.


Sherlock, Kevin Posted on 2003-07-23 15:34:22.0Z
Message-ID: <3F1EAAF9.8204C37B@qwest.com.nospam>
Date: Wed, 23 Jul 2003 10:34:22 -0500
From: "Sherlock, Kevin" <ksherlo@qwest.com.nospam>
Reply-To: ksherlo@qwest.com.nospam
Organization: QWEST DEX
X-Mailer: Mozilla 4.79 (Macintosh; U; PPC)
X-Accept-Language: en,pdf,ko
MIME-Version: 1.0
Subject: Re: Manifest constant substitution (and header files)
References: <ObpteZPUDHA.346@forums-2-dub>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: np45.qwest.com 155.70.39.45
Lines: 67
Path: forums-1-dub!forums-master.sybase.com!forums-2-dub.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:1315
Article PK: 95555

Pre-processors are everywhere. No real need to add this to isql in my mind.

I use "m4" (very popular and standard on unix systems, probably . Here
is what I do:

/home/code/defines.sql
define(_OBJ_UPPER_,2000)
define(_OBJ_LOWER_,2004)

/home/code/sproc.sql
include(defines.sql)
...
where obj_id BETWEEN _OBJ_UPPER_ AND _OBJ_LOWER_


$ m4 /home/code/sproc.sql > /home/code/sproc.postm4.sql

or

$ m4 /home/code/sproc.sql | isql -U... -P... -S...

Frank_Hamersley wrote:
>
> One thing that always bugs me about SQL is the lack of an inherent mechanism
> for compile time substitution of manifest constants.
>
> This is probably viewed as unfashionable in the 21st century but in times
> past (particularly with assembler) it greatly reduced the risk of latent
> bugs when code was being revised at a later date, but allows for use of
> constants (over variables) to improve execution times.
>
> This need just arose yet again as I was doing a code walk through on an
> infrequently executed sproc and discovered the coder had forgotten to add an
> extra constant to an IN clause like...
>
> obj_id IN (2000,2001,2002)
>
> This was due to the original work of adding new cases 2001 and 2002 being
> followed up a month later with the 3rd (overlooked) case and the scan of the
> code base not catching the coders eye. It should have read ...
>
> obj_id IN (2000,2001,2002,2003)
>
> I know this can be done in a few lines of perl and ensure that it always
> gets resolved by using makefiles to parse/compile modified stored proc
> scripts into the target server, but I think the keeping it all in the family
> is desirable. Obviously you could build a better schema that had it all in
> tables, but there are always oversights/unforeseen requirements changes (and
> time pressure) that prevents the building of that bit more structure that
> makes it perfect being table driven ;-).
>
> I could reserve a range of numbers so maintenance demands on a BETWEEN
> clause are reduced, but constructs like below are much more elegant in
> protecting against future changes without adding excess or arbitrary ranges.
>
> /home/code/defines.sql
> %DEFINE %OBJ_LOWER% 2000
> %DEFINE %OBJ_UPPER% 2004
>
> and
>
> /home/code/sproc.sql
> %INCLUDE /home/code/defines.sql
> .....
> obj_id BETWEEN %OBJ_LOWER% AND %OBJ_UPPER%
>
> Clearly extensions like this will affect portability, but if you have
> developed a system in Sybase, there is no reason why isql could not have a
> switch to write out the post processed text for extradition to elsewhere!
>
> Cheers,
>
> Frank.


Frank_Hamersley Posted on 2003-07-24 09:18:11.0Z
From: "Frank_Hamersley" <terabite@not.bigpond.com>
References: <ObpteZPUDHA.346@forums-2-dub> <3F1EAAF9.8204C37B@qwest.com.nospam>
Subject: Re: Manifest constant substitution (and header files)
Date: Thu, 24 Jul 2003 19:18:11 +1000
Lines: 106
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4927.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Message-ID: <eDzEOXcUDHA.330@forums-2-dub>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: ESS-p-144-138-7-214.mega.tmns.net.au 144.138.7.214
Path: forums-1-dub!forums-master.sybase.com!forums-2-dub.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:1316
Article PK: 95556

Your point is well taken...m4 et al can do the job most adequately!

However the main thrust of my argument remains that if the preprocessor were
more tightly integrated with the product (isql and sql advantage for
instance) it would be that little bit easier to encourage its use as the
cost of entry would be much lower.

Hopefully then better coding practices would naturally occur...in the
meantime I guess its make and scripts with m4!

Cheers,

Frank.

"Sherlock, Kevin" <ksherlo@qwest.com.nospam> wrote in message
news:3F1EAAF9.8204C37B@qwest.com.nospam...
> Pre-processors are everywhere. No real need to add this to isql in my
mind.
>
> I use "m4" (very popular and standard on unix systems, probably . Here
> is what I do:
>
> /home/code/defines.sql
> define(_OBJ_UPPER_,2000)
> define(_OBJ_LOWER_,2004)
>
> /home/code/sproc.sql
> include(defines.sql)
> ...
> where obj_id BETWEEN _OBJ_UPPER_ AND _OBJ_LOWER_
>
>
> $ m4 /home/code/sproc.sql > /home/code/sproc.postm4.sql
>
> or
>
> $ m4 /home/code/sproc.sql | isql -U... -P... -S...
>
>
>
> Frank_Hamersley wrote:
> >
> > One thing that always bugs me about SQL is the lack of an inherent
mechanism
> > for compile time substitution of manifest constants.
> >
> > This is probably viewed as unfashionable in the 21st century but in
times
> > past (particularly with assembler) it greatly reduced the risk of latent
> > bugs when code was being revised at a later date, but allows for use of
> > constants (over variables) to improve execution times.
> >
> > This need just arose yet again as I was doing a code walk through on an
> > infrequently executed sproc and discovered the coder had forgotten to
add an
> > extra constant to an IN clause like...
> >
> > obj_id IN (2000,2001,2002)
> >
> > This was due to the original work of adding new cases 2001 and 2002
being
> > followed up a month later with the 3rd (overlooked) case and the scan of
the
> > code base not catching the coders eye. It should have read ...
> >
> > obj_id IN (2000,2001,2002,2003)
> >
> > I know this can be done in a few lines of perl and ensure that it always
> > gets resolved by using makefiles to parse/compile modified stored proc
> > scripts into the target server, but I think the keeping it all in the
family
> > is desirable. Obviously you could build a better schema that had it all
in
> > tables, but there are always oversights/unforeseen requirements changes
(and
> > time pressure) that prevents the building of that bit more structure
that
> > makes it perfect being table driven ;-).
> >
> > I could reserve a range of numbers so maintenance demands on a BETWEEN
> > clause are reduced, but constructs like below are much more elegant in
> > protecting against future changes without adding excess or arbitrary
ranges.
> >
> > /home/code/defines.sql
> > %DEFINE %OBJ_LOWER% 2000
> > %DEFINE %OBJ_UPPER% 2004
> >
> > and
> >
> > /home/code/sproc.sql
> > %INCLUDE /home/code/defines.sql
> > .....
> > obj_id BETWEEN %OBJ_LOWER% AND %OBJ_UPPER%
> >
> > Clearly extensions like this will affect portability, but if you have
> > developed a system in Sybase, there is no reason why isql could not have
a
> > switch to write out the post processed text for extradition to
elsewhere!
> >
> > Cheers,
> >
> > Frank.


Michael Peppler Posted on 2003-07-24 12:32:07.0Z
From: "Michael Peppler" <mpeppler@peppler.org>
Subject: Re: Manifest constant substitution (and header files)
Date: Thu, 24 Jul 2003 14:32:07 +0200
User-Agent: Pan/0.13.4 (She had eyes like strange sins.)
Message-ID: <pan.2003.07.24.12.32.07.853920@peppler.org>
References: <ObpteZPUDHA.346@forums-2-dub> <3F1EAAF9.8204C37B@qwest.com.nospam> <eDzEOXcUDHA.330@forums-2-dub>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: 222.53.203.62.dial.bluewin.ch 62.203.53.222
Lines: 27
Path: forums-1-dub!forums-master.sybase.com!forums-2-dub.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:1317
Article PK: 95559


On Thu, 24 Jul 2003 19:18:11 +1000, Frank_Hamersley wrote:

> Your point is well taken...m4 et al can do the job most adequately!
>
> However the main thrust of my argument remains that if the preprocessor
> were more tightly integrated with the product (isql and sql advantage for
> instance) it would be that little bit easier to encourage its use as the
> cost of entry would be much lower.
>
> Hopefully then better coding practices would naturally occur...in the
> meantime I guess its make and scripts with m4!

Maybe someone should write an isql clone in perl :-)

Speaking of isql clones, I wonder if sqsh couldn't be made to do some of
this - after all it has some pretty interesting features for variable
interpolation.

Michael
--
Michael Peppler Data Migrations, Inc.
mpeppler@peppler.org http://www.mbay.net/~mpeppler
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.mbay.net/~mpeppler/resume.html