Re: In answer to RW - again (was: Sorts (revised)
From: Richard (riplin_at_Azonic.co.nz)
Date: 07/16/04
- Next message: JerryMouse: "Re: Combining Fields From Files Without COBOL Pgm?"
- Previous message: JerryMouse: "Re: Testing external file existance"
- In reply to: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- Next in thread: Chuck Stevens: "Re: In answer to RW - again (was: Sorts (revised)"
- Reply: Chuck Stevens: "Re: In answer to RW - again (was: Sorts (revised)"
- Reply: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Jul 2004 19:30:04 -0700
robert.deletethis@wagner.net (Robert Wagner) wrote
> It's refreshing to see a serious reply rather than the usual invective. Thank
> you.
The only difference seems to be that you actually agree that you were
wrong (or as close as you are likely to get to doing this). You seem
to dismiss other attempts at correcting your errors as 'the usual
invective'.
> Fujitsu and IBM have integrated SQL into the compiler.
Fujitsu does for a subset using ODBC (or unixODBC on Linux). IBM does
for DB/2. It seems that if other databases are required then the
vendor's preprocessor would still be used.
> I've never seen DECLARE in application programs. That's an oddity. The check
> is against existing tables.
The check _might_be_ against existing tables.
> Dictionary? In Oracle, that would be the table ALL_OBJECTS.
When I look at Oracle documentation it talks about the Dictionary.
> >> My experience was on all the best-selling databases. Your ad hominem is
> >> supplying bad information to innocent readers. You are telling them it
> >> cannot be done when, in fact, it is done routinely.
> Hmmm. <light goes on> You might be right.
So, you agree that yours was the 'ad hominem' ?
> I've not seen applications do database administration, but it is
> hypothetically possible.
It is not just hypothetically possible, it is not particularly
unusual. While you may be working with single machines in single
sites or where a specialist DBA does all the grubby bits, others are
distributing systems over many branches or clients where users can be
relied on to be users.
> I'd set them up as an external ODBC data source.
What you would or would not do on your sites is up to you (or your
superiors) but you wouldn't do it where the client is remote and
firewalled.
> >It seems to work very well as it does currently, what _advantage_
> >would there be in your suggestion ?
>
> The interaction between compiler and database would be defined by an external
> Standard rather than being ad hoc defined by the database provider. This would
> make source code portable.
Which _particular_ parts that are not currently 'source code portable'
would be improved by defining how the pre-processor and compiler
interract ?
In fact what part does 'interraction' play _at_all_ in the source code
?
> Again, portability and external controls.
Be specific, what is non-portable now that this interract would change
? Which lines of source code would be different ?
> Good question. In the past, language standards lived on islands that didn't
> communicate with other islands.
Actiually, in the past, they did. Cobol had 'ENTER language' in the
early standards to allow other languages to be incorporated. This is
obsolete in ANS'85.
Note that other forms of the ENTER also existed and were replaced by
CALL and the extension ENTRY.
- Next message: JerryMouse: "Re: Combining Fields From Files Without COBOL Pgm?"
- Previous message: JerryMouse: "Re: Testing external file existance"
- In reply to: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- Next in thread: Chuck Stevens: "Re: In answer to RW - again (was: Sorts (revised)"
- Reply: Chuck Stevens: "Re: In answer to RW - again (was: Sorts (revised)"
- Reply: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
