Re: Creating dds source from SQL Tables

[Tom Liotta <qsrvbas@xxxxxxxxxxxx>]

Dave Odom wrote:

>    Those from the real
> DB2s and ORACLE, etc. would laugh at you after they found out what you
> meant about "traditional record access" and how you consider DB2/400
> industry standard.   They'd think you were out of the '70s or perhaps
> the early '80s.


For some reason, this reminded me of a comment I saw on some old 
OS/2 newsgroup back shortly after OS/2 version 2 came out. The 
comment was added to a thread about accessing the OS2.INI and 
OS2SYS.INI registry files.

Now, back then, a "Windows" system pretty much meant Win3.x or the 
new-fangled Win95, with WinNT starting to make a serious push. Most 
general usenet posts were of the Win3.x and Win95 variety; this 
particular post came from someone in that group.

The OS2.INI and OS2SYS.INI files were not text files like the 
earlier DOS CONFIG.SYS kinds of files used by Win3.x/95. If you 
wanted to poke around in OS2.INI, you didn't simply fire up a text 
editor and have at it. You needed a program that could read the 
entries, format them for viewing, accept new values and write the 
entries back out correctly. Writing such a program was a fairly 
common task for a lot of us who wanted to learn how the registry 
files could be used.

The poster had been reading the comments and had to add his own 
disdainful remarks about how unbelievably difficult it was for OS/2 
users to edit their registries. "C'mon, you fools! Why do you want 
to use such an operating system? I can edit mine with any text editor!"

Of course, I suspect that poster might have had a shock or two when 
it became clear that Win2K was the appointed successor to Win98 and 
that the Windows registry was headed in the same direction as OS/2 
had gone. I would've loved to watch as he first tried to edit his 
new Windows 2000 registry with Notepad!

It's not a perfect parallel by any means with the current topic.

But I get a kick out of thinking that an Oracle or perhaps SQL 
Server database file cannot be read by native file access functions, 
whatever the native operating system platform is. I just opened a MS 
SQL Server database in Notepad. I didn't make any changes, of 
course; but it would've been rewritten if I had. (Not intending to 
equate SQL Server with Oracle!)

So, I'm not clear on what the issue is with record-level access 
through a native I/O function.

Okay, sure, I'm familiar with Codd's rules. One that really seems 
interesting here is rule 12: The /nonsubversion/ rule:

"If the system provides a low-level (record-at-a-time) interface, 
then that interface cannot be used to subvert the system, for 
example, bypassing a relational security or integrity constraint."

Not being a Unix expert, I don't know much about what Unix supplies 
in the way of native access. So I don't know if I write a C program 
that can poke around inside of Oracle "files" without using Oracle 
APIs or statements.

But I don't see a lot of ways that I can 'subvert' a SQL database by 
coding an RPG program to READ/WRITE records on my AS/400. I suppose 
it's possible, but I don't see it happening much.

Now, the word "system" in rule 12 would refer to Oracle rather than 
the host operating system if I understand it correctly. That's where 
a possible separation might be needed between DB2 on System i and 
native I/O on System i. That is, if I employ record-level access, it 
shouldn't be labeled as being "DB2 record-level access". By 
expanding the "DB2" label to cover all native data file I/O, the 
expansion makes things appear to be outside of a standard RDBMS 
universe.

But the scope of the label doesn't change whether a thing can be 
done on any given system platform.

If I choose, I can go either way on System i -- I can create and 
manage via SQL or I can ignore SQL entirely. The fact that native 
I/O is acknowledged and accommodated while maintaining whatever 
database integrity has been defined seems reasonable to me. I can't 
add/change/delete records that violate constraints, AFAIK.

But if I can access a given Oracle file by coding a regular old C 
program and manage to make a change that messes something up, then 
I'm misunderstanding something.

Maybe installing Oracle means that Unix gets patched so that 
"native" access is prohibited against Oracle tables? ...I'd get some 
kind of file I/O error returned? That could actually make some sense 
to me.

Or maybe Oracle users prefer CONFIG.SYS?

Tom Liotta