![]() | |
#21
| |||
| |||
|
|
dawn wrote: Mike Preece wrote: Excalibur wrote: "Mike Preece" <michael (AT) preece (DOT) net> wrote in message news:1154103783.390914.180920 (AT) s13g2000cwa (DOT) googlegroups.com.. snip>. So - size constraints are necessary on the client, and they're necessary in the DBMS too. That driver program I mentioned is, of course, within the DBMS. However I agree with Dawn they must not be locked into the DBMS, they must be a layer above the DBMS. In that way we do not get locked into the pain of an SQL DBMS design, we can retain the beauty of Pick. See "Demarkation!..." above. Everything you need to connect to the DBMS to achieve is at some layer *within* the DBMS. As for the "locked-in" bit - these things aren't locked-in, and almost certainly never will be. Still - I reckon it'd be damn silly to accept data without any validation or integrity checking. I agree with what both you and Dawn *mean* - that this should not be at the IO level, and agree that it should be at the level of input validation, but it just has to be seen as going on *within* the DBMS. Mike. It sounds like our differences might just be about the term DBMS, also mentioned in another thread. Is code that you write part of the DBMS like constraints written in SQL are part of the DBMS? In that case, I would argue for constraint handling "within the DBMS". I might have to get a better handle on that DBMS term as I suspect that I use it inconsistently myself. Thanks. --dawn Yes, I have to confess I do too - although not so often these days as I once did. It's all down to the fact that for so long Pick stretched to the horizon, from my perspective. As Mark reminded us, it used to be all-encompassing - a complete OS, DBMS, Application Development Environment, the lot. Now it's just a DBMS - albeit an extremely agile and capable one. My view on this changed as a result of my forays into Bob Badour's territory. (See: http://tinyurl.com/h46ku ) Cheers, Mike. |
![]() |
| Thread Tools | |
| Display Modes | |
| |