RE: [U2] [OT] Cost of Oracle vs PICK

2004-06-09 Thread Phil Walker
Here you go.

Phil Walker
+64 21 336294
[EMAIL PROTECTED]
infocusp limited
\\ PO Box 77032, Auckland New Zealand \ www.infocusp.co.nz
DISCLAIMER:  This electronic message together with any attachments is
confidential.  If you are not the intended recipient, do not copy, disclose
or use the contents in any way. Please also advise us by return e-mail that
you have received the message and then please destroy. infocusp limited is
not responsible for any changes made to this message and / or any
attachments after sending by infocusp limited. We use virus scanning
software but exclude all liability for viruses or anything similar in this
email or any attachment

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Michael Preece
Sent: Wednesday, June 09, 2004 11:37 AM
To: [EMAIL PROTECTED]
Subject: RE: [U2] [OT] Cost of Oracle vs PICK

Sorry for the *very* late reply... (been otherwise
occupied - and there was a *lot* in my u2-users inbox
to get through)

 --- Dennis Bartlett [EMAIL PROTECTED] wrote:  Ross

  The hooks are more or less in place ...
 [Triggers]

 Ah! Triggers!

 Triggers as implemented in UniVerse are limited.

Why people don't change their READ, WRITE, DELETE 
RELEASE statements to CALL FILEIOSUBR(...) I really
don't know. Relatively easy to do. If you just give it
some thought you'll see the enormous benefits. You can
pass the subroutine a real filename (as in string) as
opposed to a file variable - no need for OPEN
statements in your code (other than in the IO
subroutine(s)). The subroutine can convert that
filename to an actual pathname and check its
shared/named common list of open files to see if it
needs to be opened (so you only need to open any file
once per session). You can very easily introduce your
own triggers for *any* activity connected with the
file - including READs. If you want to take this
further, you can then more easily introduce a data
abstraction layer - allowing you to redesign a poorly
designed database - normalise it even. Changes at the
FileIO/database level can be accomodated in the FileIO
subroutine layer without any changes being required to
the code that calls the FileIO subroutine. Go on -
give it some thought - you'll soon see the light.

Cheers
Mike.


 There is no read trigger - for historical reasons,
 none that
 apply today
 - the fact remains - you cannot base what a user
 sees or
 doesn't see on
 a trigger, as the trigger will only be actived on
 insert,
 update, or
 delete, and forcing an update just to activate a
 trigger
 seems a little
 pointless, wouldn't you say?

 Triggers cannot be applied to Type 1 / 19 files. Not
 that
 much of a
 limitation if it's data that you're seeking to
 contain.
 Bu*mm*er if it's
 source access you're worried about - and after all,
 if I can
 get to the
 source, I can work out how to get to anything else.

 Having a file type (1/19) that works just like a
 directory
 is just
 asking for trouble. Anyone with notepad can get in,
 look at,
 change,
 destroy, and the IT department wouldn't even know.

 Data security? Ha! All I need to beat UniVerse
 security [on
 Gatesware]
 is access to the server. Access to the server will
 give me
 the ability
 to create a dummy account and thence gain
 fiddle-ability to
 all...

 To create a dummy account all I need do is write an
 entry
 into
 UV.ACCOUNTS. How do I do this?
 (1) I use Explorer to get a copy of the UV.ACCOUNTS
 file
 from the server
 (via the OS), I write it into my copy of UniVerse PE
 as the
 local
 UV.ACCOUNTS file, add the necessary record, eg
 GOTCHA, use
 same faithful
 explorer / midnight commander to write said file
 back onto
 server.

 (2) Use UniVerse PE to create a  universe account
 with TCL
 access
 rights, use Explorer to copy onto server, as GOTCHA,
 in
 correct place as
 defined in UV.ACCOUNTS entry added in step (1).

 (3) Login to new GOTCHA account, set qfile pointers,
 avoid
 hacking
 highly security system entry controls coz I don't
 need to,
 and besides
 that would force an update, and hence a trigger.

 (4) No read trigger, therefore no knowledge that
 I've
 accessed your
 data. I've copied it all to my system, I've copied
 your
 source to my
 system, I've copied your dictionaries to my system.
 Even on
 runtime
 sites, the lack of source code doesn't prevent me
 from
 knowing all there
 is to know about your company.
 ---
 u2-users mailing list
 [EMAIL PROTECTED]
 http://www.u2ug.org/listinfo/u2-users

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [OT] Cost of Oracle vs PICK

2004-06-09 Thread Dennis Bartlett
Ta mate!

-Original Message-
  Here you go.
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] [OT] Cost of Oracle vs PICK

2004-06-08 Thread Michael Preece
Sorry for the *very* late reply... (been otherwise
occupied - and there was a *lot* in my u2-users inbox
to get through)

 --- Dennis Bartlett [EMAIL PROTECTED] wrote:  Ross
 
  The hooks are more or less in place ...
 [Triggers]
 
 Ah! Triggers!
 
 Triggers as implemented in UniVerse are limited.

Why people don't change their READ, WRITE, DELETE 
RELEASE statements to CALL FILEIOSUBR(...) I really
don't know. Relatively easy to do. If you just give it
some thought you'll see the enormous benefits. You can
pass the subroutine a real filename (as in string) as
opposed to a file variable - no need for OPEN
statements in your code (other than in the IO
subroutine(s)). The subroutine can convert that
filename to an actual pathname and check its
shared/named common list of open files to see if it
needs to be opened (so you only need to open any file
once per session). You can very easily introduce your
own triggers for *any* activity connected with the
file - including READs. If you want to take this
further, you can then more easily introduce a data
abstraction layer - allowing you to redesign a poorly
designed database - normalise it even. Changes at the
FileIO/database level can be accomodated in the FileIO
subroutine layer without any changes being required to
the code that calls the FileIO subroutine. Go on -
give it some thought - you'll soon see the light.

Cheers
Mike.

 
 There is no read trigger - for historical reasons,
 none that
 apply today
 - the fact remains - you cannot base what a user
 sees or
 doesn't see on
 a trigger, as the trigger will only be actived on
 insert,
 update, or
 delete, and forcing an update just to activate a
 trigger
 seems a little
 pointless, wouldn't you say?
 
 Triggers cannot be applied to Type 1 / 19 files. Not
 that
 much of a
 limitation if it's data that you're seeking to
 contain.
 Bu*mm*er if it's
 source access you're worried about - and after all,
 if I can
 get to the
 source, I can work out how to get to anything else.
 
 Having a file type (1/19) that works just like a
 directory
 is just
 asking for trouble. Anyone with notepad can get in,
 look at,
 change,
 destroy, and the IT department wouldn't even know.
 
 Data security? Ha! All I need to beat UniVerse
 security [on
 Gatesware]
 is access to the server. Access to the server will
 give me
 the ability
 to create a dummy account and thence gain
 fiddle-ability to
 all...
 
 To create a dummy account all I need do is write an
 entry
 into
 UV.ACCOUNTS. How do I do this?
 (1) I use Explorer to get a copy of the UV.ACCOUNTS
 file
 from the server
 (via the OS), I write it into my copy of UniVerse PE
 as the
 local
 UV.ACCOUNTS file, add the necessary record, eg
 GOTCHA, use
 same faithful
 explorer / midnight commander to write said file
 back onto
 server.
 
 (2) Use UniVerse PE to create a  universe account
 with TCL
 access
 rights, use Explorer to copy onto server, as GOTCHA,
 in
 correct place as
 defined in UV.ACCOUNTS entry added in step (1).
 
 (3) Login to new GOTCHA account, set qfile pointers,
 avoid
 hacking
 highly security system entry controls coz I don't
 need to,
 and besides
 that would force an update, and hence a trigger.
 
 (4) No read trigger, therefore no knowledge that
 I've
 accessed your
 data. I've copied it all to my system, I've copied
 your
 source to my
 system, I've copied your dictionaries to my system.
 Even on
 runtime
 sites, the lack of source code doesn't prevent me
 from
 knowing all there
 is to know about your company.
 ---
 u2-users mailing list
 [EMAIL PROTECTED]
 http://www.u2ug.org/listinfo/u2-users 

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/