Copying fields in backend

[nesalc]

Hi Access Group.

Can somebody help me with my problem.

Scenarium:

I have an Access backend, only with tables ;-). These tables are
updated with data written from a program which is not developed in
Access. I have no forms in the backend in which I can call Modules or
Subcodes.

What I need is that when the table "tbl_prod" has been updated with
new data, then the text value of field "tbl_prod.Article" is to be
copied into the emty field "tbl_prod.Barcode" of the updated record.

Is it possible to made this copy only in the table field settings, or
can it be done without Forms. How can I get the "copycode" executed
when new data has been written to the table. This backend is then used
by a machine in which it is not possible to change the software or
field relations (interface).

If You can help me with this, then it will minimize a lot of errors
with wrong manual keyed in Barcodes.

Best Regards

Class Olsen

 

[Douglas J. Steele]

Why? In general, it's a bad idea to store data redundantly, which is what it
sounds like you're trying to do.

 

[nesalc]

Hi Douglas.

Thank you for your quick reply. As a former database administrator I
agree with you at any time that it is a bad idea to store data
redundantly. But in this case I think that I have no choise. Normally
the mentioned fields are stored with different data but this case the
data is the same, so in order to minimize the numbers of errors I can
accept the stored data.

The machine which is looking into the table fields have an interface
in which I cannot change.

Do you have an idea.

Thank you in advanced

Regards Class

 

[Douglas J. Steele]

Can you create a query that duplicates that field and have the machine look
at that query rather than the table?

There's no equivalent to triggers in Access, so there's no way to
automatically run code after data insertion at the table level. (When you're
working with forms, you can use the AfterInsert or AfterUpdate events)

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)


Hi Douglas.

Thank you for your quick reply. As a former database administrator I
agree with you at any time that it is a bad idea to store data
redundantly. But in this case I think that I have no choise. Normally
the mentioned fields are stored with different data but this case the
data is the same, so in order to minimize the numbers of errors I can
accept the stored data.

The machine which is looking into the table fields have an interface
in which I cannot change.