![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I wish to eat my cake and have it, too. Can you help a poor, starving data glutton? I am using VFP 6. The app that I have created and continue to support has grown considerably since I started. Some of the shortcuts that I had to take earlier are biting me. I like having field-level entry validation. I like to see errors being caught as soon as possible. (My boss likes this, too.) For example, if an invalid client code is entered, it is caught right away, not when the whole record has been entered. All of the tables are free tables. I would like to use a database and get into having data validation in one place. I do not see how I can use the database validation to validate data entry field-by-field. (If I am wrong about this latter point, PLEASE let me know how to deal with the situation.) I really do not like the idea of having to write two sets of validation: one for the database and one for data-entry validation. It is too easy for them to get out of sync, and since this app is somewhat fluid, this would be all too easy. (To be fair, with free tables, all of the validation is currently in the app. I feel that I am just barely holding on though.) n-tier does sacrifice the user interface somewhat, but does it necessarily have to? Has anyone come up with an approach that avoids the validation duplication but allows for field-level entry validation? Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. |
#3
| ||||
| ||||
|
|
I am using VFP 6. I suggest you upgrade to VFP8 or VFP9 when it is released. Not only |

|
All of the tables are free tables. I would like to use a database and get into having data validation in one place. I do not see how I can use the database validation to validate data entry field-by-field. (If I am wrong about this latter point, PLEASE let me know how to deal with the situation.) |
|
I really do not like the idea of having to write two sets of validation: one for the database and one for data-entry validation. It is too easy for them to get out of sync, and since this app is somewhat fluid, this would be all too easy. Don't! |
|
(To be fair, with free tables, all of the validation is currently in the app. I feel that I am just barely holding on though.) n-tier does sacrifice the user interface somewhat, but does it necessarily have to? Has anyone come up with an approach that avoids the validation duplication but allows for field-level entry validation? If feasable start using biz objects to apply the rules. |
#4
| |||
| |||
|
|
Gene, When a table is in a database, you have access to both field validation AND record validation, as well as triggers for insert, update and |
|
In n-tier design, you normally have a Business Rules layer that validates all the data at whatever (and how many) levels you choose. |
#5
| |||
| |||
|
|
"Rick Bean" <rgbean (AT) unrealmelange-inc (DOT) com> wrote: Gene, When a table is in a database, you have access to both field validation AND record validation, as well as triggers for insert, update and delete. Besides field validation, you can specify the field valid error message and a default value. Just create as test database and add a couple test tables to see all the possibilities! Hmm, my previous try with the database approach must have been way more limited than I had thought. I was only using it as a container, but I missed whole sections. I did get a simple one-table example to work with append. With a form, what do I do? 1) .controlsource for the fields seems obvious. 2) What about catching at the app level that a validation error occurred? on error or what? 3) Any other gotchas here? I am very much a fan of having my code where I can see it. How do I get a copy into a text file of what rules are in the database? And, how do I reverse this? In n-tier design, you normally have a Business Rules layer that validates all the data at whatever (and how many) levels you choose. These can be coordinated with the DBC or not. How are business rules implemented? Where does this middle layer go? So far, I have only seen the hoopla and not the VFP implementation. From experience, I know that the devil is in the details. I have an existing system that must be kept running. The existing system includes frequent adjustments. This means that it is very important for me to get this right. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. |
#6
| |||
| |||
|
|
"Rick Bean" <rgbean (AT) unrealmelange-inc (DOT) com> wrote: snip I am very much a fan of having my code where I can see it. How do I get a copy into a text file of what rules are in the database? And, how do I reverse this? |
|
In n-tier design, you normally have a Business Rules layer that validates all the data at whatever (and how many) levels you choose. These can be coordinated with the DBC or not. How are business rules implemented? Where does this middle layer go? So far, I have only seen the hoopla and not the VFP implementation. From experience, I know that the devil is in the details. I have an existing system that must be kept running. The existing system includes frequent adjustments. This means that it is very important for me to get this right. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. |
#7
| |||
| |||
|
|
Field validation rules happen any time you change the data and try to leave the field - whether in a browse/grid or in a control that uses |
|
To read all the "rules", the best documentation is to use the GENDBC.prg on your database. It will produce a program that you can use to |
|
N-Tier design (including Biz rules) is a huge topic, and you can find a number of articles out there. One to start with is one on the |
#8
| |||
| |||
|
|
"Rick Bean" <rgbean (AT) unrealmelange-inc (DOT) com> wrote: I have just graduated from a two-year program where we did cover n-Tier, but it was in VB6. I am looking for the implementation details in VFP. It just occurred to me that I should ask for good books on n-Tier implementation in VFP, so... What are some good books on n-Tier implementation in VFP? |
#9
| |||
| |||
|
|
I like having field-level entry validation. I like to see errors being caught as soon as possible. (My boss likes this, too.) For example, if an invalid client code is entered, it is caught right away, not when the whole record has been entered. |
#10
| |||||
| |||||
|
|
Gene Wirchenko seemed to utter in news:k308b0hpabhbh8uc422ftus0aa765oijo2@ 4ax.com: [snip] I like having field-level entry validation. I like to see errors being caught as soon as possible. (My boss likes this, too.) For example, if an invalid client code is entered, it is caught right away, not when the whole record has been entered. A possible option: 1) Move the tables into a DBC |
|
2) For each field needing validation logic, write a stored procedure that performs the needed checks. |
|
3) If you want validation to occur in triggers and other table-based validation hooks, call the stored procedure from there. |
|
4) In forms, just call the stored procedures when needed to do more graceful validation for the user. |
|
This puts all your validation code in one place so changes to any validation need to be made only once. There are other ways to centralize validation code like this as well. |
![]() |
| Thread Tools | |
| Display Modes | |
| |