Charlotte Foust
charlotte.foust at gmail.com
Sun Mar 18 12:59:56 CDT 2012
True, John, but I was simplifying. Charlotte On Sun, Mar 18, 2012 at 9:15 AM, jwcolby <jwcolby at colbyconsulting.com>wrote: > > or you are binding to fields in more than one table. > > Even that is not strictly true. AFAICT it really has to do with the form > being bound to a query with one-to-one recordsets. > > For example, in one client I have a query where the form is bound to a > fairly long string of tables - claimant / claim / policy etc. However, > while the tables themselves are one to many, each policy can have many > claims, each claimant can have several claims, the form query only pulls a > single policy record, a single claimant and a single claim. > > JET can uniquely identify WHICH EXACT RECORD in each table should be > updated. That form is in fact updateable in any of the tables, and I do in > fact bind updateable controls to each of those tables. > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 3/18/2012 9:46 AM, Charlotte Foust wrote: > >> What you say is only true if the query is not constructed to be updateable >> or you are binding to fields in more than one table. What version of >> Access are you working with? >> >> Charlotte Foust >> >> On Sun, Mar 18, 2012 at 5:53 AM, Non-Linearly<nonlinearly@**gmail.com<nonlinearly at gmail.com>> >> wrote: >> >> "I don't get the not updateable part" >>> Well in Access a form can be bound to a table or query. If we have a >>> table >>> or query without joins to other tables then the form is updateable which >>> means that every time you edit a record then the changes automatically >>> saved! >>> If don't (the form is bound to a query with joins to other tables) then >>> you >>> have not this feature (you cannot edit any record in form). >>> So the solution is a form bound to a query without join that has a where >>> clause to filter the records based on user's security level. >>> >>> -----Original Message----- >>> From: accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com> >>> [mailto:accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com>] >>> On Behalf Of Benson, William >>> (GE Global Research, consultant) >>> Sent: Sunday, March 18, 2012 12:37 PM >>> To: Access Developers discussion and problem solving >>> Subject: Re: [AccessD] Split table's records according to user acoount >>> >>> Why on earth.... >>> >>> Until you wrote what you did in response to Charlotte, hers is exactly >>> the >>> solution I imagined.... >>> >>> >>> A user has a security level, and the record has a security level, and any >>> time a user has a security level above that required for the record, they >>> can see it. >>> >>> You need joins to the user privileges table. >>> >>> I don't get the not updatable part. >>> >>> I am not much good with that aspect, I believe it is handled through >>> relationships. >>> >>> Dunno - but quality databases do it all the time. Absolutely, users >>> never >>> see the table. Only a view prepared for them. >>> >>> -----Original Message----- >>> From: accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com> >>> [mailto:accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com>] >>> On Behalf Of Non-Linearly >>> Sent: Sunday, March 18, 2012 4:03 AM >>> To: 'Access Developers discussion and problem solving' >>> Subject: Re: [AccessD] Split table's records according to user acoount >>> >>> Thank you very much, so in the worst case I need so many levels of >>> security >>> as there are users... >>> (although in this worst case that I do not have overlap then it will the >>> same to assign each record with a user account). >>> >>> Thanks >>> >>> -----Original Message----- >>> From: accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com> >>> [mailto:accessd-bounces@**databaseadvisors.com<accessd-bounces at databaseadvisors.com>] >>> On Behalf Of William Benson >>> Sent: Saturday, March 17, 2012 7:54 PM >>> To: Access Developers discussion and problem solving >>> Subject: Re: [AccessD] Split table's records according to user acoount >>> >>> Dont assign users to records assign security levels to both user and >>> records. >>> On Mar 17, 2012 1:02 PM, "Non-Linearly"<nonlinearly@**gmail.com<nonlinearly at gmail.com>> >>> wrote: >>> >>> I want the records in a table to distribute according to its users. I >>>> could create a field that holds for each entry, the user that has the >>>> rights to see it. But the problem is that a record may need to be >>>> viewed from more than one user! >>>> >>>> So I made a second table that more than one records each with the user >>>> account and the id from the first record. So with this way I can >>>> assign more than one user to one record. >>>> >>>> But then more problems emerge: >>>> 1. To take the records assigned to a specific user I have to run a >>>> query that join the above tables. The form that is bound to this query >>>> cannot be updateable! >>>> >>>> 2. The query can be achieved only with IN operator and is very very >>>> very slow. >>>> >>>> >>>> >>>> Thanks >>>> >>>> -- >>>> AccessD mailing list >>>> AccessD at databaseadvisors.com >>>> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >>>> >>>> >>>> >>> >>> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>>> >>>> >>>> >>> >>> >>>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >>> >>> >>> >>> >>> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>> >>> >>> >>> >>> >>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >>> >>> >>> >>> >>> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>> >>> >>> >>> >>> >>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >>> >>> >>> >>> >>> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>> >>> >>> >>> >>> >>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> >>> >>> >>> >>> >>> Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >>> >>> >>> >>> >>> >>> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> > > > Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> > > >