[AccessD] Access and SQL Server

Darryl Collins Darryl.Collins at iag.com.au
Tue Mar 1 17:49:41 CST 2011


_______________________________________________________________________________________

Note: This e-mail is subject to the disclaimer contained at the bottom of this message.
_______________________________________________________________________________________



Ditto.  I don't even ask if it is what the client wants.  I know they will need it one day.

Had a classic case of this sort of thing where I work.  Been banging on at some folks here since November that their "It is our source of truth and there is nothing wrong with it" XL Spreadsheet is going to cause them (severe) grief sometime soon as their role expands.

5 months later they have decided that perhaps they do need to talk to me after all...  aaaah, the sound of little light bulbs going "ping!".

Cheers
Darryl.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 2 March 2011 4:47 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Access and SQL Server

When I create a table in any datastore, the first thing I do is create an autoincrement PK.  I no 
longer even think about it - if need a table, I need an autonumber pk!

I then proceed to create the fields.

John W. Colby
www.ColbyConsulting.com

On 3/1/2011 12:17 PM, Jim Lawrence wrote:
> Many years ago I was taking over an Access project as the clients were
> having problems with their invoices. After about two days I discovered the
> problem with the invoice.
>
> It appears that the subform was connected to the main form by grouping
> together 3 fields, creating natural foreign key between the two tables. By
> some odd set of bad luck certain combinations of this key hash matched
> another unrelated key value and the sub form data was pulling from multiple
> invoice details.
>
> The only reliable solution was to move all the tables to auto PKs but it
> cost the client a fair chunk of change. For that reason I have never
> inflicted natural keys, on a client, no matter how strong the temptation.
>
> Jim
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan
> Sent: Monday, February 28, 2011 3:00 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Access and SQL Server
>
> I see a lot of sense in it having a separate Autonumber PK.   This is a
> classic case of why
> you should not use a natural key as your PK.
>
> What happens when the Description changes and the existing Code is no longer
> an accurate
> short representation of Description?  Do you change it throughout all the
> tables which store it
> or do you leave your customer with strange Codes which don't match the
> description
>
> (And please don't tell me that you use Relationships with "Cascade Update"
> turned on.)
>
>
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________________________________________________

The information transmitted in this message and its attachments (if any) is intended 
only for the person or entity to which it is addressed.
The message may contain confidential and/or privileged material. Any review, 
retransmission, dissemination or other use of, or taking of any action in reliance 
upon this information, by persons or entities other than the intended recipient is 
prohibited.

If you have received this in error, please contact the sender and delete this e-mail 
and associated material from any computer.

The intended recipient of this e-mail may only use, reproduce, disclose or distribute 
the information contained in this e-mail and any attached files, with the permission 
of the sender.

This message has been scanned for viruses.
_______________________________________________________________________________________




More information about the AccessD mailing list