Jim, I don't know if this is an avenue for your investigation, but, even if both tables are defined in the form, i.e. Parent/Master and Child/Slave, do they share 1 or more common columns to link them and are these columns properly defined with correct names and data-types? I ask particularly since you describe the use of 2 temp' tables in the form and, human nature being what it is, I could easily see any of us creating temporary tables with "mangled" column definitions.
RBase enforces "good" naming integrity, f/ex: `InvoiceID` has the same definition throughout the database. So, "mis-matched" column definitions would inadvertently sever the relationship between 2 tables. I think this strictness is a very wise and proper thing, based on problems I've encountered - even last week - in other systems where too much latitude not only allows us to name the same data as `InvoiceID`, `Invoice_ID`, `InvoiceNUM`, `InvoiceNUMBER`, etc., but sometimes even to define it with different data types in different tables. Anyway, this is just 1 thought (of the very few I have in my head today). Also, over the past few months, I have begun using temporary tables more regularly in the fashion Razzak describes, in the On Before Design and On Before Start EEPs of a form. A lot of times, I will create those temp' tables via the PROJECT command, which can be a time-saver, at least when an existing table's structure is the layout required. That said, somewhere, perhaps in the documentation/help files or in the mail archive or in one of Razzak's "FTE"'s (From The Edge). It's simple, but somehow, I had missed it, even though I really, really appreciate it's benefits when using PROJECT to create a temp' table based on an existing table. On the chance that it could help you, too, here it is: PROJECT TEMPORARY temp_MY_EMPTY_TABLE FROM MY_NOT_SO_EMPTY_PERMANENT_TABLE USING * WHERE LIMIT=0 The piece I had never learned or had forgotten is the "... WHERE LIMIT=0". This creates an empty table, ready to "rock-n-roll". I had been "thick" enough that I was just projecting the entire table, data included, then deleting everything from it. It's wonderful what a little illumination by reading can bring to a person. (Ever read Plato's "Allegory of The Cave"?) Well, that's my not-as-good-as-Razzak's-but-HTH Tip of the Day. Steve in Memphis -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jim Belisle Sent: Sunday, July 18, 2010 8:17am 08:17 To: RBASE-L Mailing List Subject: [RBASE-L] - Re: mdi forms Razzak, Now that I know MDI forms can use temporary tables, I can do my detective work. I will have to check my code. On the particular form I am talking about, I create two temp tables, one of which is in a scrolling region. I will have to find out why the scrolling region table is not being created. That is the error I get - no table found. I just want to take this time again to thank you Razzak for having a forum like this where people can get information "on the fly" so to speak. For someone like myself, that does programming on the side, it has been invaluable. Also all the forms, tables etc we receive when we purchase the product have made me look smart when I meet the needs of our users. I hope as RBASE grows with continued success these "extras" are not ever dropped. Jim -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of A. Razzak Memon Sent: Saturday, July 17, 2010 10:21 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: mdi forms At 06:34 PM 7/17/2010, Jim Belisle wrote: >I have been successful in getting forms to come up as MDI >when they are based on tables. I have so far been unable >get other forms to come up as MDI that use temp tables. Is >this always true? Is there some special programming that I >must do for temp tables to be used as MDI? > >Jim > >Sorry! I meant to say FORMS BASED on temp tables to be used >as MDI. Jim, Any form used as MDI, either a Variable Form, or a form based on a permanent/temporary table, should always work as expected. In your specific case, just make sure that the actual temporary table is defined prior to using the form as MDI. Where in your routine are you defining TEMPORARY table(s) for all those MDI forms based on TEMPORARY tables? Did you know that you can define the appropriate temporary table(s) related to any specific form as "On Before Design" and "On Before Start" EEP? Also, keep in mind that all TEMPORARY Tables/Views are DROPped when using the DISCONNECT command. Last but not least, you may TRACE your routine to pin down the actual problem. Very Best R:egards, Razzak. --- RBASE-L =======================3D=======================3 D= TO POST A MESSAGE TO ALL MEMBERS: Send a plain text email to [email protected] (Don't use any of these words as your Subject: INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) =======================3D=======================3 D= TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: INTRO =======================3D=======================3 D= TO UNSUBSCRIBE: Send a plain text email to [email protected] In the message SUBJECT, put just one word: UNSUBSCRIBE =======================3D=======================3 D= TO SEARCH ARCHIVES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: SEARCH-n (where n is the number of days). In the message body, place any text to search for. =======================3D=======================3 D=
