Another possibility is to pre-fill in the record with default data such as
00000-0000 for the zip code and update the record IFF the user enters valid
data. That way if the zip field is left incomplete, the record won't get
updated but the conduit still gets something valid to work with. If your
conduit is crashing because data is invalid and not incomplete, than never
mind.
This method does sort of leave the edit-in-place model.
-----Original Message-----
From: Richard Hartman <[EMAIL PROTECTED]>
To: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>
Date: Friday, April 02, 1999 1:04 PM
Subject: RE: Strategy for navigation & validation
>The easiest (although possibly not most elegant)
>approach to both problems would be to maintain
>two separate databases, one w/ validated records
>and one w/ incomplete records.
>
>Although both would be sync'd, the mainframe
>software app would only be getting data from
>the validated db -- the scratch db would just
>be dumped in your \pilot\<username>\backup
>directory.
>
>--
>-Richard M. Hartman
>[EMAIL PROTECTED]
>
>186,000 mi./sec ... not just a good idea, it's the LAW!
>
>
>> -----Original Message-----
>> From: Bob Ebert [mailto:[EMAIL PROTECTED]]
>>
>>
>> The downside is you've got to write a bunch of code that
>> checks for, warns
>> on, filters out, and displays incomplete records. It's
>> probably not too
>> hard, but it's an additional 'attribute' of data that a user
>> has to learn
>> about and keep track of.
>>
>> And you still have to handle the case where incomplete
>> records are present
>> when you're uploading data to the government datbase,
>> preferably without
>> crashing said database or invisibly ignoring the partial records.
>>
>>
>
>
