Hi Chris,

If you realy need those transactions (there is no need for a simple table. Just FLOCK it. TRANSACTION FLOCKS the table, write to a buffer and END TRANSACTION writes the buffer to the table and unlock while ROLLBACK clears the bufffer and unlock. If you don't need ROLLBACK FLOCK should be fine) you may put the table with the report information in an extra DBC - even if the table is the only element in it.

It depends a little bit how you distribute the data. Do you ship those table with your report app or is it created on customers comp?
Is there just one prefabricated database to your main app or can you create databases on the fly? Where do you store the report information, in main datas directory or in special one? If you have multi databases, spans the report settings over those, or are they special for each database? Includes "Save Reports" the creation of new ones or is just altering existing ones?

Noirmaly my approch is a table that ships with the app (it's compiled into the app) that holds the data for the stuff inside the app.

On useres comp I create a new table with "userdata", in this I store the things the user alters (new reports, as he can not alter build in ones)

Agnes
>Hello Everyone,
>
>I have an app that is dedicated soley to reports. My main application calls the report app to run a report. This is for updating reasons. If my users want a new report then I simply have to distribute the report app and not the entire project. In my report app I have the ability to save reports. The save feature simply saves the settings the user chose. When the user clicks the save button it goes through a series of selections,scans and inserts. I just designed this and it works great, but I want to be sure I don't have a problem when it comes to production. I created a free table that stores the report settings rather than placing the table in the DBC. The only reason I did this was to keep the report app completely independent of the main app.
>
> With that said, I just wanted to get some advice whether or not this is a good approach. Due to the fact I'm using a free table I can't issue a Begin Transaction or End Transaction to ensure the report settings are saved. I haven't used free tables in the past so I'm not sure how reliable they are when it comes to updating them. I have a feeling it would be better to place the table in a DBC and use the transaction functions, I just like the idea of having a single table without any baggage.
>
>Your comments are welcome, I just want to make the best choice.
>
>Thanks!
>
>Chris