Charlotte Foust
charlotte.foust at gmail.com
Sun Jan 4 09:57:27 CST 2015
You can use ADO to return values and update recordsets "on demand" without having a table link. Or you can open another database in code to perform updates without having a link in the current database. Charlotte On Sun, Jan 4, 2015 at 5:09 AM, James Button <jamesbutton at blueyonder.co.uk> wrote: > Add to that BLOB's stored in a separate database (Access file) > And structures where the main (indexed and linking) keys were stored in one > table while the non-indexed data were stored in a separate table. > > That enables the keydata to be held in cache for searches etc. while the > bulk > data would be accessed directly by index, and only referenced when the > appropriate main key had been identified via the searches etc. and the > main > block of data was to be reviewed or updated. > Maybe a memo field for commentary re history of activities - free form > text in > the form of an essay etc. > Or maybe the converse of your suggestion - the non-secure information such > as > background details to clinical details of procedures etc. than can be > pretty > much publically accessed by researchers, while the details that would allow > identification of the subject are kept securely inaccessible. > > Yes - it may be more secure to not have any link from the open data to the > secure data, but there needs to be some link for maintenance and maybe > contacting the subject if there is an appropriate requirement identified > from > searching the open data. > > Social services and health records create some 'interesting' requirements > that > may need 'non-confirmative' approaches > > JimB > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tina Norris > Fields > Sent: Saturday, January 03, 2015 9:17 PM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Confused by One to Many versus One to One > > In fact, the only way I've ever seen a 1-to-1 relationship used was to > make a table of confidential employee data that shouldn't appear in the > general employee info table. I read an example once, suggested for a > library database, but I honestly didn't understand it at all. > TNF > > Tina Norris Fields > tinanfields-at-torchlake-dot-com > 231-322-2787 > > On 11/30/2014 2:57 PM, Jim Dettman wrote: > > Bill, > > > > It's pretty rare to have a 1 to 1. Pretty much everything will be a 1 > to M > > or a M to M. > > > > Jim. > > > > -----Original Message----- > > From: accessd-bounces at databaseadvisors.com > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Bill Benson > > Sent: Friday, November 28, 2014 07:52 PM > > To: 'Access Developers discussion and problem solving' > > Subject: [AccessD] Confused by One to Many versus One to One > > > > I almost never make relationships one to one, and yet my databases always > > seem to "work." By work, I mean that I never seem to run into situations > > where I cannot accomplish what I want to, in terms of record insertion, > > queries, etc. So I now have a situation where maybe that is not a good > idea. > > > > > > > > I have Order and Product tables, one order can contain many products. So > I > > required an OrderProducts table to distribute the same OrderID across > > numerous ProductIDs. > > > > > > > > My question is, should the relationship between the Order and > OrderProduct, > > on the OrderID and FKOrderID, be 1-to-1, or 1-to-many? > > > > > > > > Likewise, the same question for the OrderProduct and the Product, on the > > ProductID and the FKProductID? > > > > > > > > > > > > -- > 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 >