[AccessD] Sort of like a filter only not

Exactly.

--
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 11:11


Andy

You need to show the real customer data to the specific customer while
hiding all other data that is in the system for other customers?

Martin



----- Original Message -----
From: "Gustav Brock" <gustav at cactus.dk>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Friday, December 12, 2003 11:03 AM
Subject: Re: [AccessD] Sort of like a filter only not


> 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
>

_______________________________________________
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