dbTalk Databases Forums  

Field- and Record-Level Validation / Database-Level Validation

comp.databases.xbase.fox comp.databases.xbase.fox


Discuss Field- and Record-Level Validation / Database-Level Validation in the comp.databases.xbase.fox forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Gene Wirchenko
 
Posts: n/a

Default Field- and Record-Level Validation / Database-Level Validation - 05-25-2004 , 09:42 PM






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.

Reply With Quote
  #2  
Old   
Rick Bean
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 07:52 AM






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!

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.

Rick

"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote

Quote:
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.

Reply With Quote
  #3  
Old   
Gene V
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 09:18 AM




Gene Wirchenko wrote:

Quote:
I am using VFP 6.
I suggest you upgrade to VFP8 or VFP9 when it is released. Not only
does this give you access to a lot of new features, it helps keep the
fox around

Quote:
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 never use a database for data validation, that is up to the biz
object layer to apply the bisiness rules. The databases should only
have to worry about the integrity of the data NOT the accuracy. This
way you can re-use database design across different apps without
worrying about the business rules that would apply to that data.

Quote:
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!

Quote:
(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.



Reply With Quote
  #4  
Old   
Gene Wirchenko
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 11:28 AM



"Rick Bean" <rgbean (AT) unrealmelange-inc (DOT) com> wrote:

Quote:
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?

Quote:
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.


Reply With Quote
  #5  
Old   
Rick Bean
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 01:01 PM



Gene,
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 the field as a controlsource - think of it as a global Valid method. You don't have to "catch" it, VFP will! (This can be problematic in cases where you want to override it!)

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 recreate the database. If you want, you can use this program as the basis of some code that would produce more readable documentation. Remember that a DBC is nothing more than a DBF with a extra flag set in the header. You can USE it and process it like any other table!

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 Stonefield site at http://www.stonefield.com/techpap.html - "N-Tier Application Design". Many of the frameworks also use (and the documentation discusses) a business rules layer. A place to start for framework comparisons is http://fox.wikis.com/wc.dll?Wiki~FrameworkFeatureChart.

Rick

"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote

Quote:
"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.

Reply With Quote
  #6  
Old   
Rush Strong
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 01:04 PM




"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote

Quote:
"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?
Open the database, right click, and select "Edit stored procedures." Also,
see the docs for the GENDBC program. (You may have to locate it within your
VFP hierarchy - look for ...\Tools\GenDBC\GenDBC.prg). GENDBC produces a
..prg file which contains all the code needed to generate your DBC from
scratch.

- Rush

Quote:
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.



Reply With Quote
  #7  
Old   
Gene Wirchenko
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 07:07 PM



"Rick Bean" <rgbean (AT) unrealmelange-inc (DOT) com> wrote:

Quote:
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
the field as a controlsource - think of it as a global Valid method.
You don't have to "catch" it, VFP will! (This can be problematic in
cases where you want to override it!)

I want to know how to, at the app level, catch this happening.

It is possible that this is not the right question to ask. If
so, please explain why.

Quote:
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
recreate the database. If you want, you can use this program as the
basis of some code that would produce more readable documentation.
Remember that a DBC is nothing more than a DBF with a extra flag set
in the header. You can USE it and process it like any other table!

gendbc? I thought I was going to hear that.

Quote:
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
Stonefield site at http://www.stonefield.com/techpap.html - "N-Tier
Application Design". Many of the frameworks also use (and the

Thank you. Bookmarked.

documentation discusses) a business rules layer. A place to start for
framework comparisons is
http://fox.wikis.com/wc.dll?Wiki~FrameworkFeatureChart.

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?

[snipped previous]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.


Reply With Quote
  #8  
Old   
Rush Strong
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-26-2004 , 07:38 PM



"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote

Quote:
"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?

Here's a good place to start:

http://www.hentzenwerke.com/catalogp...ts/aoopvfp.htm

(On sale, half off, till midnight (CST), 5/27, USA).

- Rush




Reply With Quote
  #9  
Old   
Tim Witort
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-27-2004 , 10:48 AM



Gene Wirchenko seemed to utter in news:k308b0hpabhbh8uc422ftus0aa765oijo2@
4ax.com:
[snip]
Quote:
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.

-- TRW
_______________________________________
My e-mail: t r w 7
@ i x . n e t c o m . c o m
_______________________________________


Reply With Quote
  #10  
Old   
Gene Wirchenko
 
Posts: n/a

Default Re: Field- and Record-Level Validation / Database-Level Validation - 05-27-2004 , 06:01 PM



trw7at (AT) ixdot (DOT) netcomdotcom (Tim Witort) wrote:

Quote:
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
OK.

Quote:
2) For each field needing validation logic, write a stored
procedure that performs the needed checks.
OK.

Quote:
3) If you want validation to occur in triggers and other
table-based validation hooks, call the stored procedure
from there.
How?

Quote:
4) In forms, just call the stored procedures when needed to
do more graceful validation for the user.
How?

Quote:
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.
I think I need a simple example of how 3 and 4 would work.
Assume a table silly
thekey c(10) trimmed must end with a digit
thedata c(40) trimmed must be at least ten characters long
record-level thedata must start with the same digit that
thekey ends with.

What goes in each form and control method?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.