Re: [Gnumed-devel] catching errors in an app

[Karsten Hilbert]

On Sat, Feb 18, 2006 at 07:55:23PM -0800, Jim Busser wrote:

> >We need to be very careful here not to jump to invalid
> >conclusions. The postal system constraints you mention have
> >nothing to do with storing the data itself.
> If CR/LF/FF were permitted to be stored with data i.e. inside a 
> column, couldn't such characters frustrate programmatic efforts to 
> present the data in the way needed? That is all that I meant.
Ah, I see. Yes, you are right, that can certainly be a
problem down the road ! I didn't think of that...

> Is it proposed to be added here (but not everywhere) partly because 
> it is the likeliest point where users like secretaries might 
> type/input such characters -- and/or the likeliest situation where 
> these characters risk being imported among data from a legacy or 
> interoperating app?
That's one reason. Another reason would be that there
*should not* be any such characters in those fields -- until
a counter-example is shown to exist.

> >field called "street" or "town" is sufficiently fine-grained
> >for *any* postal system to be able to say: This field is
> >*never* supposed to contain any LF/CR ?... I was asking you
> >guys to reinforce my suspicion with your experience before
> >I put this constraint into the database itself.
> 
> FWIW I agree. Presumably aux_street, addendum, urb and suburb can 
> fill the other needs an address might have?
Exactly, that's what they are intended to do.

I'll add the constraints.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346