|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
