[AccessD] Primary Key Best Practices

That's cheating, John.  From an interface, you need a PK.  Why bother to
be a stickler about anything if you're going to play directly in the
tables?

Charlotte 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, July 25, 2007 4:56 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary Key Best Practices

Charlotte,

>You'd still need an identity field to edit it in SQL Server.

No, in fact you do not!  I have all these huge 1 table databases that I
am currently using.  They are lists of people / addresses / information
about the people.  They stand alone, at least initially.  I always
create an ANPK but...

I just created a table in SQL server consisting of two fields char(10),
text1 and text2.  I saved the table, then I opened the table and edited
the data, directly in SQL Server.  No PK, I could edit the data.  I
entered new data records, I went back and edited existing data.  I
deleted rows.  I can do any of the things that you are saying cannot be
done, with out a PK, or even an index.  Just plain old simple char()
fields.  Not an index in sight, never mind a unique index.  No PK.  I
can add records, I can edit existing records, I can delete records,
directly in the table in SQL Server.

In fact my client used these huge data tables (lists of addresses) to
create name / address lists that they sold to their clients long before
I ever hit the scene.  Just one table.  They did not understand nor care
about PKs.
There were no child tables so no pointer was needed to get back to the
parent.  No unique index can be created, because there are in fact
duplicates.  They create hashes in order to discover and get rid of the
duplicates in the output but there is no field, nor combination of
fields that uniquely identify a specific record.  The client uses (makes
a LOT OF
MONEY) off of these tables.

Is this a database?  I can't answer that.  It is a standalone (extremely
large) table in a big iron database management system.  It generates
millions of dollars a year for the owners.  They do not in fact ever
edit it, but they could if they wanted to, at least inside of SQL
Server.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Wednesday, July 25, 2007 5:50 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Primary Key Best Practices

You're picking nits, John.  You'd still need an identity field to edit
it in SQL Server.  If the unique key exists, you have a functional PK,
whether you call it that or not. 

Charlotte Foust 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, July 25, 2007 2:47 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary Key Best Practices

Any database made up of a single table would not require a PK. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com