A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Primary Key help



 
 
Thread Tools Display Modes
  #1  
Old May 4th, 2004, 07:46 PM
Bill A
external usenet poster
 
Posts: n/a
Default Primary Key help

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.

  #2  
Old May 5th, 2004, 12:08 AM
John Vinson
external usenet poster
 
Posts: n/a
Default Primary Key help

On Tue, 4 May 2004 11:46:40 -0700, "Bill A"
wrote:

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.

John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public
  #3  
Old May 5th, 2004, 10:46 PM
external usenet poster
 
Posts: n/a
Default Primary Key help

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?

-----Original Message-----
On Tue, 4 May 2004 11:46:40 -0700, "Bill A"
wrote:

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.

John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public
.

  #4  
Old May 5th, 2004, 11:34 PM
Tim Ferguson
external usenet poster
 
Posts: n/a
Default Primary Key help

wrote in
:

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

  #5  
Old May 6th, 2004, 02:14 AM
Jessestonecedar
external usenet poster
 
Posts: n/a
Default Primary Key help

You think you must but you don't know enough to know must. (kindly said) Rich.
  #6  
Old May 6th, 2004, 06:10 AM
test
external usenet poster
 
Posts: n/a
Default Primary Key help


"Jessestonecedar" wrote in message
...

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


  #7  
Old May 10th, 2004, 11:14 PM
John Vinson
external usenet poster
 
Posts: n/a
Default Primary Key help

On Wed, 5 May 2004 14:46:00 -0700,
wrote:

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.

John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 06:53 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.