[AccessD] Sort of like a filter only not

Martin Reid mwp.reid at qub.ac.uk
Fri Dec 12 08:38:14 CST 2003


If the data only has to be for a client at that specific time or for  a
sales meeting then it would be fairly simple to repopulate a duplicate DB
with data for that client. Simple but time consuming.

This seems to be one of those things that would need to be coded in from day
one. Think I would go with your first idea and just bite the bullet instead
of recoding the database.

Martin


----- Original Message ----- 
From: "Andy Lacey" <andy at minstersystems.co.uk>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Friday, December 12, 2003 2:28 PM
Subject: RE: [AccessD] Sort of like a filter only not


> Sorry, reading my original again I may have misled you Jim. We're not
> talking about a situation where a customer permanently has a system with
> their data on it. We're talking about situations such as customer A coming
> to these premises for a meeting for a day and my client wanting to be able
> to show them the system on-screen but limited only to their data, OR a
sales
> person going travelling with a laptop onto which we have downloaded the
> system (this we do already - for enquiry purposes only) and having
meetings
> with several customers over several days. So we need to be able, fairly
> quickly, to say "I'm going into a meeting with X so make the system show
> only X and Y's data (where Y is X's sister company)".
>
> --
> 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 19:03
>
>
> Andy,
>
> Partial replication. Each customer would have a replicated MDB with only
> their data.
>
> Jim Dettman
> President,
> Online Computer Services of WNY, Inc.
> (315) 699-3443
> jimdettman at earthlink.net
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Andy Lacey
> Sent: Friday, December 12, 2003 5:46 AM
> To: accessd at databaseadvisors.com
> Subject: [AccessD] Sort of like a filter only not
>
>
> 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)?
>
>
> --
> Andy Lacey
> http://www.minstersystems.co.uk
>
> ________________________________________________
> Message sent using UebiMiau 2.7.2
>
> _______________________________________________
> 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
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



More information about the AccessD mailing list