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/
