AGP said:
Im familiar with the statement:
UPDATE tblSource, tblTarget
SET tblTarget.Field1= tblSource.Field1, tblTarget.Field2= tblSource.Field2
WHERE tblTarget.MyID= tblSource.MyID
However, what if i have a big amount of fields to copy and they strutures of
both tables are exactly the same? is there a way to shorten that SQL
statement or do i have to explicitely write all fields to be copied?
tia
AGP
I am encountering the same problem after management decided to commit
spreadsheet on a form. Think of an Order/OrderDetails arrangement where
each OrderDetail can have a breakout that looks like OrderDetails and
sums back to the original OrderDetail. The actual situation is quite a
bit more complicated since several "orders" can be grouped together and
the entire group must be available simultaneously for editing, not to
mention a few other wrinkles. Groan. For edits I copy the existing
data into local tables and use those. When the user is done editing the
local tables (Add, Edit, Delete), I use the following logic:
1. Update any records in the linked table that match records in the
local table.
2. Append any records to the linked table from the local table that
don't match in the linked table.
3. Delete any records in the linked table that don't match in the local
table.
In this instance a match is based on two foreign keys both matching.
Only one user will be editing a given set of data at a time.
This problem is similar to the BOM problem except that only a few levels
are used. This problem seems to be the kind that benefits from the use
of a class since Albert Kallal recommends classes for complicated
situations. This is certainly that.
I like Jamie's idea of using, say, a tabledef to assist in creating the
SQL string. I was able to save a little space by using:
UPDATE tblLinked AS A INNER JOIN tblLocal AS B ON (A.QEID = B.QEID) AND
(A.QDID = B.QDID) SET A.Field1 = B.Field1, ...;
The Append query also lists each field. My guess is that if fields are
left unspecified, Access will append the fields in the order of the
SELECT statement. I don't want to roll the dice so I think I'm stuck
with listing the fields. If I get a little busy for awhile it's because
I'm beating on this Whak-a-Mole. Here, however, the Whak-a-Mole is not
new bugs popping up, but bizarre feature creep. I typically spend less
than 1% of my time fixing bugs. I get paid for putting in the new
features, but I'd rather be working on other kinds of new functionality.
James A. Fortune
(e-mail address removed)