In My larger systems...
I have a folder with an alias "APP" or "TBL" and I create and saved all non
user data tables (priv entry tables, report tables, static data tables, etc.)

All forms and reports (and libs) then use PRIV as intended. 
I have the calling code or init method copy the table from APP to PRIV before
the open. The init of the form can do this and works for any PRIV table (1:1,
1:M) as needed.



As I work in the app I would table copy the tables in PRIV to a "save priv"
folder. Then I have a batch file that copies all "save priv" to PRIV and
I can open any object in design mode.
Then another batch to empty PRIV for run testing. Most of the "app" tables
for PRIV would be empty and small.




other option:
design the reports and forms to open USING the APP folder for design and
switch to priv at runtime. That way you can design as needed. This works
only with (under normal conditions) forms and reports with one main table.



I have seen many apps where the developer uses the create table on the fly
in the init or calling code. it works, but is a PITA to develop in...





Mark Bannister <markRemove@THISinjection-moldings.com> wrote:
>It is more steps, but you can also call that code from some other form 
>or library without opening the form with created tables.  It makes 
>development MUCH easier.  The first time you mess something up and have

>to temporarily replace the table on your form you understand why.
>
>On 5/21/2019 2:54 PM, Kevin Baker wrote:
>> Mark,
>> 
>> Thanks for this.  I don't have a deep working knowledge of libraries,
so 
>> to be clear, on my form I open a library, run code from the library that

>> creates the db.  And I put this code (running the code from the library)

>> on the init of the form.
>> 
>> Is this correct?  If so, then how is it different than what I'm doing

>> now?  To me it would seem like it is adding more steps to run the code

>> from a library.
>> 
>> Thanks,
>> Kevin
>