[AccessD] Sort of like a filter only not

Now there's a thought. Thank you Gustav, I hadn't even considered that, and
now will.

--
Andy Lacey
http://www.minstersystems.co.uk




--------- Original Message --------
From: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] Sort of like a filter only not
Date: 12/12/03 10:05


Hi Andy

We have the same need. As it is close to impossible to create and
maintain a set of demo-data that mimics real life, we pick a copy of a
relevant client's data and "anonymise" these by renaming all customers
and other identifiable data (like employees' names and project names)
to fantasy names.

/gustav


> Morning everyone. Poets day is with us again but in the meantime I'm
looking
> for bright ideas here.

> I have a biiiiig system here. I mention that it's big because any solution
> to this cannot involve changing every screen, report and query that's
> affected - far too much work. And the challenge is this: the users
want/need
> to put selected parts of the system in front of customers. When they do
so,
> however they do not want to show the names of other customers. So, for
> example, if they pull down a combo to select a customer they don't want to
> suddenly show that the customer's main competitor is also a customer. If
> they print a report of what the customer has received in the past 12
months
> they don't want to accidentally request All Customers and be embarrassed
> like that. In other words, in that situation, the system needs to be
> cast-iron certain to only ever show the details of one customer, or at
least
> a controlled sub-set (may be more than one as the customer may belong to a
> group).

> So my idea was that before the meeting one could run a process which would
> extract all data for the required customer(s) into an identical set of
> tables in another MDB then relink to that MDB. Not all tables would be
> affected. Look-up tables, for example, would still point to the live MDB.
> But there would be quite a few involved because I'd need the customer
table
> plus all related ones. This approach sounds ok, and an appropriate set of
> queries wouild soon do it, but it has its hassles, such as changes to the
> table structures which would require me to either keep the copy MDB
> up-to-date as well as the live one OR to create the copy one from scratch
> each time - but then I've also got to create indexes and relationships too
> and that's quite a job.

> Another idea I had, but I have to reject, was to rename the linked table
(ie
> give it a different alias) then create a query with the same name as the
> table which filters the customers. All queries, screens and reports would
> then see that. But that's out because I use SEEKs on the customer table to
> access records quickly, and I can't SEEK on a query.

> So, has anyone got a better idea? Or a simple way of resolving the issue
of
> changes in the table structures (can you somehow clone a set of tables
> complete with all indexes and relationships)?

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

________________________________________________
Message sent using UebiMiau 2.7.2