Re: having a common forms area

On Fri, 5 Feb 1999, Tam McLaughlin wrote: > Is there a way with online 5, V4 tools to have a common dir under SCO > Unix for SQL Forms? We have about 10 developers who each have about 300 > forms in their home dirs. If I could put all the forms in a common > directory where isql could see all the forms without the developers > having to cd $FORMSSQL? As someone else said, the DBPATH variable is used to locate form and report files as well as the database itself. Given that you are using OnLine, you should be OK. With SE, there was a piece of logic built into ISQL such that when it found 'stores.dbs' located as /some/where/special/stores.dbs, it would only look for forms and reports in /some/where/special. I'm pretty sure that got either removed or modified during the 4.12/6.00 releases. Looking at the release notes (TOOLREL_6.0) for 6.01.UD1, the following information was included, and at least some of this information is not present in the later versions of the TOOLREL files, and I'm not sure whether it is in the documentation anywhere. David: maybe some of this should make its way into the FAQ? Yours, Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn Extract from 6.01.UD1 file $INFORMIXDIR/release/TOOLREL_6.0 =========================================================== DBLANG ------ ISQL, I4GL, R4GL, FGLGO, FGLDB, FGLPC, and so on all now make use of DBLANG to locate their message files. In all cases, the place where the file is found is: ${INFORMIXDIR:-/usr/informix}/${DBLANG:-msg} Translated, that means if $INFORMIXDIR is set, its value is used; otherwise /usr/informix is used. Under that directory, if DBLANG is set, it is used; otherwise msg is used as the subdirectory. Do not use an absolute pathname in DBLANG (a name that starts with a slash) because it will mean that some message files are not locatable. DBFORM ------ A new environment variable called DBFORM was introduced in the 4.12 release. DBFORM is analogous to DBLANG, and allows the directory where system form files are found to be relocated under $INFORMIXDIR. These form files are now located in: ${INFORMIXDIR:-/usr/informix}/${DBFORM:-forms} By default, system form files are located in $INFORMIXDIR/forms; by setting DBFORM to forms.german, the form files from the directory $INFORMIXDIR/forms.german will be used instead. This affects ISQL for User Menu (maintenance) option, and I4GL and R4GL for the Program Compile options. If an absolute pathname is specified for DBFORM (the value starts with a slash on Unix), the forms will be searched in the specified directory without prepending $INFORMIXDIR. Note that DBFORM does not affect I4GL programs written by the user; it is solely used by the products when accessing internal forms. DBPATH is used to control the location of form files for user programs. The name DBFORM was used because there was existing code (in the Japanese version of Informix) that already used DBFORM, so the proposed name DBLANGFORM was not used when fixing bug B15148. DBOLDDBPATH ----------- In the past, if the user had selected a database in ISQL, requests for file displays (such as (D)rop script, (C)ompile form, etc.) would only show files that were in the current directory (and, in addition, for an SE database, the directory that housed the database), even if there were appropriate files in other directories specified in DBPATH. If the user had not selected a database yet, then all appropriate files in the DBPATH search path would be displayed. The new implemented behavior is that all appropriate files available in the DBPATH-specified directories will be displayed, and manipulatable, regardless of whether or not the user has selected a database (and regardless of whether those scripts, forms, or reports can work with the selected database). A new environment variable, DBOLDDBPATH, if set to any non-empty value such as 'yes', will enable the old behavior. PROGRAM_DESIGN_DBS ------------------ The new I4GL and R4GL programs acknowledge the PROGRAM_DESIGN_DBS environment variable that allows the user to choose where to store the program information. Please refer to "CHANGES TO I4GL AND R4GL" section for more detail information. SPERISOL & SACEISOL ------------------- Version 4.11 of INFORMIX-SQL provided the ability to run PERFORM forms using dirty read isolation with an OnLine backend. In Version 4.12, this feature has been extended to allow ACE reports and PERFORM forms to be run in any isolation level. This feature will only be of interest to you if you are running ISQL with OnLine, and is provided mainly to provide compatibility for those who upgrade from Standard Engine to OnLine. The following description assumes an understanding of "levels of isolation" in OnLine databases; you can find this information in your OnLine Programmer's Manual. The Standard Engine always runs in dirty read mode; the default isolation level for OnLine databases with no logging is dirty read, for MODE ANSI databases the default is repeatable read, and for databases with transaction logging the default is committed read. Each mode has a different tradeoff between isolation and concurrency. When you upgrade from a Standard Engine to OnLine, the isolation level will automatically change, as described above. Usually, the new default isolation level is more suitable than the old; however, in some cases, it will be preferable if the concurrency level remains the same under OnLine as it was under Standard Engine. This can be accomplished in 4GL by adding 4GL code that sets the isolation mode to dirty read, and it can be similarly accomplished in ISQL scripts. To set the isolation level for PERFORM, set the environment variable SPERISOL to one of the following values; similarly, to set the isolation level for ACE, set the environment variable SACEISOL to one of these values: dirty read committed read cursor stability repeatable read In Bourne Shell or Korn Shell, use: SPERISOL="dirty read" export SPERISOL In C Shell, use: setenv SACEISOL "repeatable read" The isolation level can be specified in upper- or lowercase (or mixed case), but only a single space is allowed between the words, and there must be no leading or trailing spaces. If the value in the variable is unrecognised, the variable is silently ignored, as is the error from Standard Engine. The environment variables must be set before running the ISQL program (or SPERFORM or SACEGO); trying to set it using a shell escape fro

In article <79fapf$hs6$1@news.xmission.com>, Jonathan Leffler <jleffler@informix.com> writes > >On Fri, 5 Feb 1999, Tam McLaughlin wrote: >> Is there a way with online 5, V4 tools to have a common dir under SCO >> Unix for SQL Forms? We have about 10 developers who each have about 300 >> forms in their home dirs. If I could put all the forms in a common >> directory where isql could see all the forms without the developers >> having to cd $FORMSSQL? > >As someone else said, the DBPATH variable is used to locate form and >report files as well as the database itself. > >Given that you are using OnLine, you should be OK. With SE, there was a >piece of logic built into ISQL such that when it found 'stores.dbs' located >as /some/where/special/stores.dbs, it would only look for forms and reports >in /some/where/special. I'm pretty sure that got either removed or >modified during the 4.12/6.00 releases. Looking at the release notes >(TOOLREL_6.0) for 6.01.UD1, the following information was included, and at >least some of this information is not present in the later versions of the >TOOLREL files, and I'm not sure whether it is in the documentation anywhere. > >David: maybe some of this should make its way into the FAQ? > OK, I have saved it away for inclusion. >Yours, >Jonathan Leffler (jleffler@informix.com) #include <wish/I/was/skiing.h> >Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN >Informix IDN for D4GL & Linux -- http://www.informix.com/idn > >Extract from 6.01.UD1 file $INFORMIXDIR/release/TOOLREL_6.0 >=========================================================== > > DBLANG > ------ > > ISQL, I4GL, R4GL, FGLGO, FGLDB, FGLPC, and so on all now make use of > DBLANG to locate their message files. In all cases, the place where the > file is found is: > > ${INFORMIXDIR:-/usr/informix}/${DBLANG:-msg} > > Translated, that means if $INFORMIXDIR is set, its value is used; > otherwise /usr/informix is used. Under that directory, if DBLANG is set, > it is used; otherwise msg is used as the subdirectory. > > Do not use an absolute pathname in DBLANG (a name that starts with a > slash) because it will mean that some message files are not locatable. > > DBFORM > ------ > > A new environment variable called DBFORM was introduced in the 4.12 > release. DBFORM is analogous to DBLANG, and allows the directory where > system form files are found to be relocated under $INFORMIXDIR. These > form files are now located in: > > ${INFORMIXDIR:-/usr/informix}/${DBFORM:-forms} > > By default, system form files are located in $INFORMIXDIR/forms; by > setting DBFORM to forms.german, the form files from the directory > $INFORMIXDIR/forms.german will be used instead. This affects ISQL for > User Menu (maintenance) option, and I4GL and R4GL for the Program Compile > options. > > If an absolute pathname is specified for DBFORM (the value starts with a > slash on Unix), the forms will be searched in the specified directory > without prepending $INFORMIXDIR. > > Note that DBFORM does not affect I4GL programs written by the user; it is > solely used by the products when accessing internal forms. DBPATH is > used to control the location of form files for user programs. > > The name DBFORM was used because there was existing code (in the Japanese > version of Informix) that already used DBFORM, so the proposed name > DBLANGFORM was not used when fixing bug B15148. > > DBOLDDBPATH > ----------- > > In the past, if the user had selected a database in ISQL, requests for > file displays (such as (D)rop script, (C)ompile form, etc.) would only > show files that were in the current directory (and, in addition, for an > SE database, the directory that housed the database), even if there were > appropriate files in other directories specified in DBPATH. If the user > had not selected a database yet, then all appropriate files in the DBPATH > search path would be displayed. > > The new implemented behavior is that all appropriate files available in > the DBPATH-specified directories will be displayed, and manipulatable, > regardless of whether or not the user has selected a database (and > regardless of whether those scripts, forms, or reports can work with the > selected database). A new environment variable, DBOLDDBPATH, if set to > any non-empty value such as 'yes', will enable the old behavior. > > PROGRAM_DESIGN_DBS > ------------------ > > The new I4GL and R4GL programs acknowledge the PROGRAM_DESIGN_DBS > environment variable that allows the user to choose where to store the > program information. Please refer to "CHANGES TO I4GL AND R4GL" section > for more detail information. > > SPERISOL & SACEISOL > ------------------- > > Version 4.11 of INFORMIX-SQL provided the ability to run PERFORM forms > using dirty read isolation with an OnLine backend. In Version 4.12, this > feature has been extended to allow ACE reports and PERFORM forms to be > run in any isolation level. > > This feature will only be of interest to you if you are running ISQL with > OnLine, and is provided mainly to provide compatibility for those who > upgrade from Standard Engine to OnLine. The following description > assumes an understanding of "levels of isolation" in OnLine databases; > you can find this information in your OnLine Programmer's Manual. > > The Standard Engine always runs in dirty read mode; the default isolation > level for OnLine databases with no logging is dirty read, for MODE ANSI > databases the default is repeatable read, and for databases with > transaction logging the default is committed read. Each mode has a > different tradeoff between isolation and concurrency. > > When you upgrade from a Standard Engine to OnLine, the isolation level > will automatically change, as described above. Usually, the new default > isolation level is more suitable than the old; however, in some cases, it > will be preferable if the concurrency level remains the same under OnLine > as it was under Standard Engine. > > This can be accomplished in 4GL by adding 4GL code that sets the > isolation mode to dirty read, and it can be similarly accomplished in > ISQL scripts. > > To set the isolation level for PERFORM, set the environment variable > SPERISOL to one of the following values; similarly, to set the isolation > level for ACE, set the environment variable SACEISOL to one of these > values: > > dirty read > committed read > cursor stability > repeatable read > > In Bourne Shell or Korn Shell, use: > > SPERISOL="dirty read" > export SPERISOL > > In C Shell, use: > > setenv SACEISOL "repeatable read" > > The isolation level can be specified in upper- or lowercase (or mixed > case), but only a single space is allowed between the words, and there > must be no