Continuous subform with DAO question

[Access Sortof Newb]

Good morning,

I think this problem has an easy solution, because I can't find any
other conversation related to it.

I have a form, frmPackingListCreator and it has a subform sfrmDetails
for the details of the packing list. I don't want the tables
tblPackingList and tblPackingListDetails to be updated real time, so I
left the form unbound and made the subform reference a temporary table.
Then, when all the data is entered, the user clicks the "create packing
list" and the proper tables are updated through DAO procedures. Great.
That works fine, albeit sloppy. I was wondering if there is a cleaner
way to perform this same routine or if the use of a temporary table on
the subform is all that can be done (since the subform has to be
continuous to allow for multiple record entries).

Thanks for the help

Tim

 

[Baz]

Good morning,

I think this problem has an easy solution, because I can't find any
other conversation related to it.

I have a form, frmPackingListCreator and it has a subform sfrmDetails
for the details of the packing list. I don't want the tables
tblPackingList and tblPackingListDetails to be updated real time, so I
left the form unbound and made the subform reference a temporary table.
Then, when all the data is entered, the user clicks the "create packing
list" and the proper tables are updated through DAO procedures. Great.
That works fine, albeit sloppy. I was wondering if there is a cleaner
way to perform this same routine or if the use of a temporary table on
the subform is all that can be done (since the subform has to be
continuous to allow for multiple record entries).

Thanks for the help

Tim

Hows about binding your forms as the Gods of Access intended, but having a
"confirmed" column on tblPackingList? Everything except
frmPackingListCreator ignores packing lists wot are not confirmed. You
could even think about renaming the table as "tblPackingListRaw" or
something like that, and creating a view, called tblPackingList:

SELECT * FROM tblPackingListRaw WHERE confirmed = True

That way, hopefully, all your other forms, reports etc. might not need
changing.

 

[Access Sortof Newb]

Thanks for the help; that DOES make things far easier. So out of
curiousity, when should DAO/ADO/ADONET be used?

Tim

 

[Baz]

Thanks for the help; that DOES make things far easier. So out of
curiousity, when should DAO/ADO/ADONET be used?

Tim

That's a much easier question:

1. DAO should be used whenever you are working in a classic mdb
2. ADO is unavoidable when working in an ADP, apart from that it should
never be used because it was just a flash-in-the-pan which is now obsolete
3. ADO.Net is, at the present time, irrelevant to Access.

 

[Access Sortof Newb]

Thanks for the insight

Tim

That's a much easier question:

1. DAO should be used whenever you are working in a classic mdb
2. ADO is unavoidable when working in an ADP, apart from that it should
never be used because it was just a flash-in-the-pan which is now obsolete
3. ADO.Net is, at the present time, irrelevant to Access.