Colin: As a general rule, what is a write failure going to tell me? That I've lost network connectivity to the file? That the O/S has locked the file and my write is SOL? Do I now need to implement transactions? Do I need to change every program in the application, and newly written applications, to use ON ERROR clauses for each OPEN, READ, and WRITE operation? ...or is it just a way to keep a program from bombing out? Inquiring minds want to know. :-)
The thought that the entire dbms infrastructure has been pulled out from under a program during execution is pretty scary! In addition, the thought that I need to implement ON ERROR clauses across thousands of programs, implement transaction processing, and implement another file system is pretty daunting, too. Again, I wonder what is a "Best Practices" approach to these ever increasing potentialities? :-) Bill >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Wednesday, May 23, 2007 1:21 PM >To: [email protected] >Subject: RE: [U2] [BB] U2 Enhancement Request - WRITE > >Bill; > >It *should* be checked on the write. From the time it's opened to the >time the write occurs circumstances might well have changed. For >example, a long running processes (like our overnight run) can >start and >open files which are fine. As it runs the O/S backup routine starts to >run and locks the file at the OS level. UD will error out on the write >as it does not have permission, at this point, to write to the file. > >Of course, with the belt and suspenders approach you should check it on >the open so that if there is a problem it doesn't go half way through a >routine before discovering it's unable to make a write. > >Hth >Colin Alfke >Calgary Canada > >-----Original Message----- >From: Bill Haskett > >Is this discussion identifing a preference to manage permissions at the >front end (OPEN) instead of at the back end (WRITE) in a BASIC program? >Has anyone resolved this question and come up with a general preference >one could use as a "Best Practices"? > >This knowledge would be welcome when trying to retrofit this >functionality into a current application. > >Bill ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
