Re: 4gl problems

Quoting Dick Hassler... } } I have used Dave Snyders db4glgen v3.21 for the main table and 3 subtables. } Even with modifications his code lends a consistency that makes it easy to } make modifications once you understand the code. I think it's great! } Thanks... db4glgen-3.22 is now on "mathcs.emory.edu". What's new??? The "-o" option for generating Online features! But don't get too excited yet, the option was put there for future enhancements and right now the only Online specific code genereated is the line SET ISOLATION TO DIRTY READ when "-o" AND "-l" are specified. This is done so that the read of ROWIDs during Query doesn't crap out. Ooops, I'm babbling... onward! } So I have added a 'Tables' selection to the main table's menu that when } accessed opens up another window with menu selections for the 3 subtables. } Each of the 3 subtables calls separate db4glgen modules for adding, updating } deleting the appropriate row determined by the common one column key. } } This all works 100% of the time for adds. Updates of the subtables some } times has a problem. The change is made to the column and the operator hits } Escape, the change is negated (the original data comes back) and the error } message shows at the bottom of the window: } UPDATE table (%s) is not the same as the cursor table. } I thought I had this fixed once when I 'free(d)' the cursurs in all the } subtables modules. If the operator exits the program and comes back in it } works fine (the update of the subtable). } Let me ask you this... are these seperate stand-alone .4ge programs which are RUN from the master or are these all linked into one program? Based on your description of the program and what it's doing, I'm going to assume the one-monster-program theory. YOU ARE IN FOR SO MUCH FUN :-) First of all, I've found that things work better if cursor names are UNIQUE through all the .4gl modules that comprise a single .4ge program. Change "upd_curs" to "a_upd_curs" in one of the .4gls, to "b_upd_curs in another, etc. Don't forget "std_curs", "brw_curs", and "q_curs"! This should solve the problem you described above. Now for the problem you HAVEN'T noticed yet :-) When you do a Query, the ROWIDs of the records that match your search criteria are loaded into a dynamically-allocated array by a C routine. THERE IS ONLY 1 ARRAY!!! Therefore, when you drop into one of your sub-table screens and do a Query, the array will be erased and reloaded with ROWIDs for this new query. No problems so far. What happens when you return to the main-table screen??? Now that you've figured out you got garbage ROWIDs in the array (if you don't get a "row not found" error, you'll get bogus information displayed), here's how to work around it... Thanks to TED REPH formerly of Raytheon Engineers & Constructors for this one. Ted, where the @!$#^% are you? I still have 6 Macanudo Hyde Park Cafe's that have been aging w/ the brandy in my humidor since August, 1994. Anyway... Step 1: Loose the i_rowid_s() function in your sub-table module(s) Step 2: Pass "q_cnt" from the master-table module to the sub-table module(s) you call and then copy it to a module-only global variable called "offset". Step 3: In the calls to s_rowid_s(), change the "q_cnt" to "q_cnt + offset", in the calls to r_rowid_s(), change the "q_cur" to "q_cur + offset", in the calls to w_rowid_s(), make the above changes where appropriate. By doing the above, the sub-table ROWIDs will be appended to the master-table ROWIDs instead of overwriting them. Now, if you have seperate .4ge programs... I'll have to think about it. PS - Check out my new WEB page! It has links to db4glgen-3.22 and other stuff. Later! DAS -- Dave Snyder @ Bell Atlantic - Philadelphia, PA WEB: http://www.ece.vill.edu/~dave/index.html EMAIL: (w) ddx85qr@boots.bell-atl.com (h) dave@das13.snide.com