* Carbon Copies sent to:
        David Sherman, Allan Whitworth
Hi Dave and Allan:
Sorry it took so long to get back, outbound mail snag for a few days . 
Still haven't tested the latest upgrade, but here is a partial copy of the 
letter I sent to Sheng Labs concerning problems.
D  - Prerelease D
G1 - Gamma 1
G2 - Gamma 2
... addressing deleted (RC)
This letter is to define the current problems encountered with the GAMMA
release version 2 of TurboPAL.
Problems:
D   1. The  key is presenting problems. In show array menus, the 
G1     key normally defaults on any menu choice with the name "Do_It!",
G2     TurboPAL does not duplicate this feature (key inactive). Secondly,
       I have been encountering the Internal Error 194 alot when using
       the  key. Most of the errors I have encountered are produced
       using this key (search this doc on F2).
       Followup: I was coediting a memo field and invoking my error handling
                 procs repeatedly using ERRORPROC assignments to test if it
                 was working. Pressed  and produced an Internal Error 
4.
G1  2. The ZOOM function does NOT react as expected. Using the
G2     ".." operator to eliminate case sensitivity is not working
       properly.
       For example, when searching for "TRI LINK" you must use
       "TRI.." because the "tri.." will not find a match and the
       uppercase version will. It works only when upper case is used
       for the search parameter.
G1  3. Encountered "Error within _bpfileread" twice. Was trying to access the
       Permit.DB for viewing, then restructure. Checked with Paradox, all
       appeared normal and OK (backed up & restructured). Booted the EXE
       session again and found that I could view one of the forms so I tried
       calling Permit.DB to the workspace again and produced the following
       error:
              Internal Error : 184, please call Sheng Labs
       *** NOTE: I noticed the table listing was different in that with
                 TurboPAL "Perm_Req" comes before "Permit" but in Paradox,
                 the order is reversed.
       QUESTION: Will this have any possible adverse effects that you can
                 think of?
                 It doesn't make any difference to me so long as I can call
                 up the right table by name or string variable.
G1  4. MEMO FIELDS, pressed  while coediting Pending.F1 on a names memo
       field (not in field view). Memo fields are OK until new data is
       entered, then whatever is in it becomes corrupt. Once the memo field
       is corrupted and the  key pressed in form view, the following
       error message is output:
              Internal Error : 974, please call Sheng Labs.
       If you move off the memo field (after the field has been corrupted),
       then press the  key to save, no error is produced. The memo field
       is still corrupt. This corruption can be duplicated by entering new
       data into a memo field.
G2 4a. PASSWORDED TABLES - Memo Field Corruption
       Anytime I try anything with the 1st memo field, I encounter the
       Internal Error : 190, please call Sheng Labs (other recs normal).
       The data in the 1st memo field under Paradox is still intact. If I
       try to change any of the memo field contents of records other than
       the 1st one, it doesn't show the contents after exiting field view
       and trying to field view again produces the same error (190). Field
       contents remain unchanged in Paradox (table and memo file intact).
       Followup: It appears that this ONLY HAPPENS WITH PASSWORD PROTECTED
                 TABLES. The version I was zipping up for you didn't exhibit
                 the same memo field problem when entering new data.
G1  5. When Paradox does a QUERY, it generates an ANSWER TABLE regardless of
G2     whether it is empty or not. We rely on an answer table to
       tell us if there are any matching records to the query. TurboPAL
       compiled programs do NOT appear to be generating Answer tables 
properly.
       When this condition occurs, my program attempts to copy a form to
       the current answer table and crashes with an Internal Error 114 using
       a REPLACE command (assuming wrong structure crash because I know there
       should be an answer table with identical structure when this occurs).
       Using the CANCEL command then , I can move about but as soon as I
       press  an Internal Error : 190, please call Sheng Labs.
                      (I am copying from protected tables)
       I am in a table cross referencing routine that queries a list of
       tables for specified information. I use and reuse the answer table
       continuously, copying the form(s), report(s), valchecks, etc. required
       for viewing/reporting if the table is not empty.
       Followup: I have now inserted code to delete the PrivDir() answer
                 table, and I now get beyond this point. BUT the error
                 190 is produced again on return from loop by pressing
                  (returned to original table in formview -> DoWait()).
                  should be calling a proc called CheckQuit() at this
                 point.
Comments
NET
G1  1. With the TurboPAL debugger, full speed, I crashed and it caused
       another paradox user to be dumped to DOS (network). When the TurboPAL
       EXE crashed, it removed a critical paradox file. Error message was
       Unexpected Condition: missing G:\APPS\PERMIT\Paradox.Dir (code 0)
       Leaving Paradox.              (current network drive)
       The user (an alias of myself) was in Paradox 4.5.
G2     Followup: This condition was reproduced by user in Pdx 4.5 while
                 another user compiled/linked/exe in the same directory,
                 at the same time.
G2  2. I have noticed my OS/2 system freezing up after about 2 days of
       running TurboPAL continuosly. This has become almost a regular problem
       since installation of TurboPAL. I can't seem to pinpoint the exact
       cause at this time, but the environment always included the use of
       TurboPAL in memory. I can't afford TurboPAL or network down time at
       the moment so I may move TurboPAL to a local drive to work with. This
       will test to see if it is a network issue. (It was nice to be able to
       get at it from any station I happened to be using ...) If you need any
       specific information for possible problem determination on the network
       setup, please inquire.
...
I was asked to wrap up my application and send it in for Richard Sheng to 
look at. I mailed it in and a few weeks later, Richard called to say that a 
new version is available that addresses most of the problems encountered. It 
appears that Sheng Labs places a high priority on the TurboPAL compiler.
On the general usage of TurboPAL, it works great! I did rewrite our library 
routines to work hand in hand with the compiler. I had to do a fair amount of 
lint removal in our old coding, but it was worth it. Now I can import any 
procedure, script (with many procs or just a script), or entire directories 
into my library manager painlessly, resize, adjust output scriptname, compile 
into Pdx libs and/or prepare to create a TURBOPAL EXE application with a few 
keystrokes (and very little massaging).
There is a maximum script size of 50K, any larger and you will experience 
"ghost" problems. Errors drift from  one area to another with no rhyme or 
reason. Under a DOS/Paradox environment, the problems disappear.
The DOS environment settings for TurboPAL are very important (especially when 
shelling to DOS from within your application). You have to read the manual 
where it mentions the configuration environment setup (couple of pages). Have 
managed to call all the programs I normally need.
The scripts being compiled MUST have all the procedures referenced available 
(naturally) or the compiler will display error messages telling you which 
procedures are missing (or defined more than once!). 
If you had a compiled application that had the same name as one of the tables 
you are using, it crashed the EXE. This problem, according to Sheng Labs, has 
been fixed.
In the next week or so, I'll have more information on the "latest" version. 
Looks like we are going to try compiling Renaissance and my "Complete 
Conversion" procedures to work off our current menu structures and DoWait 
information stored therein for a hopefully, very quick and easy graphical 
user environment. (what a mouthful! ;-)
Hope this helps!
Richard
(403) 244-2716
Richard_Clarke@p20.f15.n134.z1.fidonet.org
--- msgedsq 2.0.5
---------------