I'm coming in late to this but for what it's worth: If you start with a button to add a comment you can edit it on a pop-up form and insert that row easily enough to a comments table. As you quit that form and return to your main form you can use property commands to hide the [Enter] button and display an [Edit] button along with a look-up for the inserted comment.
Using a second table for Notes is defensive programming for something outside of the database's control and not an R:Base problem! You don't need to do it but a power problem, for instance, at the wrong time with a single table could mean losing the main row of data. With two tables you are likely to lose only the note data. Also you only have rows for valid comments rather than a lot of empty space. When updating Note columns the whole row is (almost) always re-written and the original row marked as deleted. In the old days it was considered a safer way to work but reliability has improved greatly so I doubt that there is any real need for a second table. I have worked with a separate notes tables for so long now that I just do it that way automatically. You might also want to consider whether there will be similar or, even, duplicate comments. If so, you can build in a menu or a number of defaults. This would, probably, be easier with a second table and form... Regards, Alastair. From: [email protected] Sent: Thursday, December 17, 2009 6:08 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Note Data type question I guess my last post to this question is this: There is no doubt that to use a second table to hold comments in this particular situation will require : A: Significant more programming (and thus error checking) to insert comment records only if needed etc. B: When editing records, more checking to see if comment records exist to display, and then having more programming to add comments at a later date. C: When accessing the main records, database traffic will be higher as checking two tables versus the one will always be more CPU and Disk intensive than pulling up one record in one table. D: More loading on the main RX3 index file due to added indexes for the ID column. E: Searches on comments will be more difficult. versus All the above go away when using a note column on the main table. Using a very slight increase in disk space with a note column on each record. (Disk space will not be an issue in reality here so thus I do not consider it a negative) Is there any REAL value in using the second table (in this particular case)? If so, what is it? I cannot really think of any but I do not always see the forest for the trees. How would my database performance, reliability and programming efficiency improve by using two tables? (Again in this instance) The old saying is that a Rolls Royce is a better quality car than a Volkswagen Bug. But the new standard of quality now includes VALUE for the intended purpose. If my only use for the car is to go 4 blocks to the store and back the Bug is a much more quality car. It gets better gas mileage, is easier to park and cost much, much less. Its replacement cost is a fraction of the Rolls. It therefore is the better quality car for the job. Certain aspects in programming can relate to the same scenario! I am thinking this is the case here. Thanks all! -Bob Thanks, -Bob ----- Original Message ----- From: "Emmitt Dove" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Thursday, December 17, 2009 9:41:20 AM GMT -06:00 US/Canada Central Subject: [RBASE-L] - Re: Note Data type question How about using a variable memo with an on-exit eep to do the insert if required? Emmitt Dove Manager, Converting Applications Development Evergreen Packaging, Inc. [email protected] (203) 214-5683 m (203) 643-8022 o (203) 643-8086 f [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, December 17, 2009 9:46 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Note Data type question Here's my problem with the #4 approach, although granted it is the most referentially correct and probably the most space efficient. The problem is: you're on an edit form for the person, and there is no comment yet in the table for this person. You have a spot on the form for the comment, and the user thinks he can just tab or enter thru the form fields and go right into the comment field and start typing. But he can't because the comment isn't there. So you have to add the row first. What is the best way of doing this? You can cheat by adding a blank row before you bring the form up, and deleting the row after you exit if they don't enter, but this fills up the table needlessly. Do you put some kind of automatic insert using an eep if they leave the first table? Again, have to insert and possibly delete.... That's the only reason I usually don't use this type of structure myself. Karen Bob, Your options are: 1) Include a TEXT datatype on every row. This eats up a lot of space without need. 2) Include a NOTE datatype on every row. This is less demanding of space, but carries the issue of the relocation of rows when the note grows beyond a certain point. 3) Include a VARCHAR datatype on every row. This is less demanding of space in file 2, and avoids the row relocation issue with NOTE types, but will consume space in file 4 for every row. 4) The linked table with the datatype of your choice. Personally, I’d opt for 4. We use that approach for comments on a bill of lading, for example, with great success. You only take up space when you require, and you can use whatever datatype you wish. ------------------------------------------------------------------------------ No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database: 270.14.111/2569 - Release Date: 12/16/09 19:52:00
