Primary Key help

[Bill A]

I use copy and paste to duplicate tables to ensure a
consistent structure for importing data from text files.
Since I've switched to SQL to handle my databases I must
use a primary key so the data can be modified. When we
copy and paste the table the primary key isn't carried
forward. Is there a mechanism to do this or do we have to
go into design view each time? This is a problem for us
with very novice users.

 

[John Vinson]

I use copy and paste to duplicate tables to ensure a
consistent structure for importing data from text files.
Since I've switched to SQL to handle my databases I must
use a primary key so the data can be modified. When we
copy and paste the table the primary key isn't carried
forward. Is there a mechanism to do this or do we have to
go into design view each time? This is a problem for us
with very novice users.

In a properly designed database system, it should VERY rarely be
necessary to create new tables! I'd suggest importing text files into
an existing table, either appending records to those previously
imported or emptying the table (with a Delete query) and appending
into the empty table. Copy and paste is not really appropriate in any
case - a MakeTable query would be preferable if you must do so.

 

[Guest]

Unfortunately, we need to keep the data of each job we do
in a separate table for a whole host of reasons, inlcuding
that we need to refer back to the table and print labels
etc.
Any other ideas?

 

[Tim Ferguson]

we need to keep the data of each job we do
in a separate table for a whole host of reasons,

Bad ones, doubtless.

Get the design right and the functions fall out easily. Anything else is
long-way-round bodging.


Best wishes


Tim F

 

[Jessestonecedar]

You think you must but you don't know enough to know must. (kindly said) Rich.

 

[test]

You think you must but you don't know enough to know must. (kindly said)

Rich.


Whatever that means!

Rich, could you please follow standard newsgroup practice & retain the text
of the whole conversation, in each post?

Otherwise it is impossible for anyone else to follow, because the previous
posts have often disappeared from their news servers.

Cheers,
TC

 

[John Vinson]

Unfortunately, we need to keep the data of each job we do
in a separate table for a whole host of reasons, inlcuding
that we need to refer back to the table and print labels
etc.

I take it you *are* aware that in 99.98% of Access databases, it's
routine to "refer back to a table", print labels, print reports, etc.
*FROM QUERIES*?

It is NOT necessary to store data in a separate table in order to
"refer back" or to "print labels". These particular operations are in
fact *better* done by storing all similar data in a single Table and
using parameter queries to select which data you want to see or to
print.

That said: if you have your own reasons (though I may consider them to
be wrongheaded) for keeping your data in spreadsheets masquerading as
Access tables, you can do so. You will need to write either VBA code
or (for SQL Server) a stored procedure to execute a Create Table query
with a Constraints clause to specify the primary key.