>>What do you have against copying some data that will be used for read-only purposes upon app. instantiation?
>
>old scars... last time I did an implementation like this it quickly became a maintentance nightmare. (starts humming time warp theme from RHPS) If the network hiccuped when that data was coming down I'd get tripped with corrupted indexes, table headers, and incomplete data structures that weren't exactly conducive to easily error trapping. Plus the cheesier machines seemed to pick the downloading data processing as their favorite place to lock up which of course was all my fault for making the workstations copy data. Plus the occaisonal power user would get the bright idea to mess with that data. And let's not forget rambunctious user who decides to do a little housekeeping on their machine and delete or move stuff around while the app is minimized.

Hola Roxanne,

Point well taken. I'll leave this as a very last resource. Users' creativity is ALWAYS a step ahead of us developers. Very true.

>
>>I also LOOOVE your suggestion about a view on a view.
>
>If ya havent noticed already I'm extremely anal retentive...

Yeah, RIGHT... Did you know that my wife flies? Really, she doesn't need a car to go to the mall... ;-)

>so let me reiterate a view on a view requires extra handling and forethought. Keep in mind that if you need to requery the combo's record source, you have to usually requery the underlying view(s) first then requery your rowsource view and since we're talking about combo's (have i mentioned lately that i hate combo's?) you have to requery the dang control too. (starts humming the old chain gang song) Needless to say I never speak up to loudly when this argument comes up because I can see the value in the opinion that this isnt a good thing to do. But I personally dont have a problem with it because I prefer any data handling to be in the dbc. < g > Ever spend hours trying to find where you stuck a stupid SQL Select into temp cursor statement? I got a few scars for that one too, thus my preference to stick this sort of thing in the dbc even if it does make me work harder.

I think that both ways of handling this problem will require extra work on our part. I personally think that your idea is at least easier to maintain exactly for the reasons you give: everything is in ONE place and I won't have to look for semi-hidden select statements somewhere in my forms or wherever I brilliantly hid it 2 years ago.

Alex