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. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
Primary Key help
You think you must but you don't know enough to know must. (kindly said) Rich.
|
#6
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|