[AccessD] Sort of like a filter only not

Jim Dettman jimdettman at earthlink.net
Fri Dec 12 08:36:43 CST 2003


Andy,

<<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)".>>

Right.

 You also said:

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

  A good way to do that would be partial replication.  You could even hand
them the database to walk away with and never fear that their going to see
another customers data.

  As you said, the system is far to extensive to go back and put filters
into.  Therefore the only thing you can do is manipulate the data.  You your
self said:

"extract all data for the required customer(s) into an identical set of
tables in another MDB then relink to that MDB."

  That first part is almost a definition for partial replication.

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 9:28 AM
To: Access Developers discussion and problem solving
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