I also use lots of drop downs to limit input options for users. Started doing simple 'how can I screw this up' tests to hopefully catch input problems. I have two people at work who are regularly 'volunteered' to be beta testers to find problems before we let it out. It's amazing how many times that 'well thought out logic system' has gaping holes that you simply do not see until the error message pops up or the report does not run correctly.
Tom Frederick President/CEO Elm City Center 1314 W Walnut Jacksonville, IL 62650 W- 217-245-9504 F - 217-245-2350 E - [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dennis McGrath Sent: Monday, August 13, 2012 7:51 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Computed Column for UPS and FedX Yep. Unless you control absolutely what options are available to the user they will find the most creative ways to input nonsense data. Dennis McGrath Software Developer QMI Security Solutions 1661 Glenlake Ave Itasca IL 60143 630-980-8461 [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Javier Valencia Sent: Friday, August 10, 2012 6:34 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Computed Column for UPS and FedX Kenny, I ran into similar problem a while back, where users were supposed to enter "O" or "C" for open or closed status of work orders, but they decided to create their own codes such as "H" for hold, "I" for in-progress and so on, even when there was another field to do just that...users tend to do that. This created a problem because reporting was based on work orders being either open or closed. I modified all data entry form so only the two option are available; if they enter a value other than "O" or "C" the values is reset to "O" and a warning message is displayed. We have not had a problem since then. Javier, Javier Valencia, PE O: 913-829-0888 H: 913-397-9605 C: 913-915-3137 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kenny Camp Sent: Friday, August 10, 2012 3:50 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Computed Column for UPS and FedX Thanks, trying to control/manage the management team's expectations for this issue. I've decided to add code to on close EEPs on many forms. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dick Fey Sent: Friday, August 10, 2012 1:12 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Computed Column for UPS and FedX Kenny Giving your invoice clerks way to much lattitude and not enough guidance. Why not limit the entry data by using a user defined combo box so you can control the entry information. Dick Fey On 8/10/2012 12:50 PM, Kenny Camp wrote: > Requesting ideas, I'm stumped. > > We are enhancing the integration RBase with our UPS and FedEx shipping > programs using Oterro. These shipping programs are looking up our > invoices for shipping information ad account numbers when the billing > should go to either the "Shipper" or "Receiver". > > This computed column expression "(ifnull((IFEQ('Ft > Chgd',acctnumout,NULL,acctnumout)),'S','R'))" works great to update > the column with "S" or "R". > > Then I use a view to display the text "Shipper" or "Receiver" which > these shipping systems read and bill accordingly. > > When I first wrote this routine I had a simple rule, if the > accountnumout is null then bill the shipper (us) else bill the > receiver with the valid accountnumout value. This works for 95% of shipping. > > Then we discovered the invoice clerks sometimes enter "Ft Chgd" so I > wrote the above expression. > > After further discovery, they would like several (maybe a dozen) text > entries (not null) that would still resolve to "S" including > "Prepaid", "Ft Chgd", "Prepaid TX", "Our Expense", etc... that they > are adding to a table. > > I don't believe I can write a computed column expression that > complicated, and since they often edit this field after the invoice is > complete, I like the way the computed column works. > > My experience with stored procedures and triggers is limited but I > believe that updating the same table with a triggered stored procedure > would cause problems (recursive). > > Just for fun I was able to write a SP that works with an update > statement, but when editing with the Data Browser gives me the > "another user has changed the data" like I expected. > > Any ideas of a better or different approach? > > Thanks, Kenny > > > >
