 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / Importing / Linking / August 2005Export data and "flag" field of data exported
I want to select data to be exported using a query. Then "flag" or mark those records in the main table that they have been exported so they can not be exported again. This is to send checks to be printed. I would be sending to an excel file or a comma delimited file that will be imported into another check writing program. Not sure how to perform the flagging of the file. Thanks for any help. Connie Connie, You simply need an Update query to set the Printed field to True. The query must have the exact same criteria as the one you use for exporting the Excel file, so they both pick up the same records. My suggestion is you save hte query and use either a macro or some code to perform the update wirgt after the export (both fired by the macro or code). HTH, Nikos Thank you for your answer. I wasn't sure how to do the query and the update query at the same time. I kept getting an error message about using an updateable query. I finally figured I'd use the first query to build a table with the data, then used that table to update to the table with the field Exported (Y/N). It works fine and it was helpful to have a temporary table that is cleared before each export. I've added a small menu that allows a cancel event if the person isn't sure if the previous checks were printed, so they don't write over the exported file before printing happens (which could be later in the day). I appreciate all the help I receive on this board. Thanks to all of you for taking the time to answer our questions! Connie > Connie, > [quoted text clipped - 6 lines] > HTH, > Nikos Building in a reversal capability in case the printing fails, definitely adds value to your app! Just note that temporary tables contribute to database bloating, so it would be wise to take some measures toward regular compaction of the database. If this is a monolithic, single user database, or a split one in which the temporary table resides in the local front end, then just setting the Compact on Close option is all you need. If, on the contrary, the temp table resides in a back end on a shared folder, you'll probably need to employ other means for overnight compaction, or compaction by the first user to open it in the morning (from the FE, before it connects, or a small VB 6.0 exe which compacts and then launches the FE), or something like that. HTH, Nikos Thanks for the added info. I am placing the temp table in the FE of the person that will send the checks to print. Also I compact on close. This should keep it clean. Connie > Building in a reversal capability in case the printing fails, definitely > adds value to your app! Just note that temporary tables contribute to [quoted text clipped - 11 lines] > HTH, > Nikos |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.