Page 1 of 1

[Solved] Documenting FORMS

Posted: Tue May 02, 2017 8:13 pm
by FKlusmann
Thanks to all who have posted here I have learned a lot! Among many other things, Tools > SQL -- > script 'C:\Hold\Test-03.sql' < -- as the Command to execute will document all the Tables, including the field types, sizes and constraints. Also the data is there. Query SQL can be taken (Copy n Paste - one at a time) from Edit in SQL view.
Is there a method get similar definitions from the FORM? Especially the Formatted Fields, the links between Master and Slave Form/SubForm, and the Content of SubForm Properties (as SQL from the ‘Content’ field?
Thank you.

Re: Documenting FORMS

Posted: Tue May 02, 2017 8:25 pm
by Villeroy
A form is just an ordinary Writer document which is opened in read-only mode when using it. File>SaveAs saves a copy of the form to the hard disk. It will lose its connection but the connection can be rebuilt so you can use it as a non-embedded stand-alone form document.
[Tutorial] Standalone Forms / Switchboard

The SQL script generated by the SCRIPT command is not for documentation only. It is the database definition. When you execute the script you get an exact clone of the database.

Re: Documenting FORMS

Posted: Tue May 02, 2017 9:36 pm
by FKlusmann
Thank you again.
Villeroy wrote:... It will lose its connection but the connection can be rebuilt ...
and ... execute the script you get an exact clone of the database.
In the way my mind works, more than the connection is lost. Form level field data validation needs to be done again, the Formatted Fields loose their formatting... I am hoping that the "inner works" of a Form could be ~documented~ by some (automated) series of commands.

Yes, SCRIPT output, when executed, recreated the tables (content & all) and relationships between tables. I did not see that Queries were also there........ I had considered these to be a component of the database.
Thank you again for teaching all of us.
-- Fred

Re: Documenting FORMS

Posted: Tue May 02, 2017 9:46 pm
by Villeroy
Only the connection to the containing database gets lost when you move it out of the container.
There is not much "inner working" in simple Base forms. A screenshot of the form navigator may be useful but not as useful as a backup of the whole thing.

Re: Documenting FORMS

Posted: Wed May 03, 2017 1:36 am
by FKlusmann
Yes,
Villeroy wrote:.... as useful as a backup of the whole thing.....
, at least every hour while making changes,,,,,,, before BASE fails on you while working on it.
I'll defer marking it solved until I return from the hospital on the off-chance that someone may have an idea. Thank you.

Re: Documenting FORMS

Posted: Wed May 03, 2017 12:23 pm
by Villeroy
FKlusmann wrote: I'll defer marking it solved until I return from the hospital on the off-chance that someone may have an idea. Thank you.
Get well soon.

Re: Documenting FORMS

Posted: Wed May 03, 2017 12:27 pm
by Villeroy
One more note on the subject: Base is not a database development suite. It is just a tiny addition to the office suite. On my Linux system the Base component takes no more than a dozend MB including the database drivers for HSQL, MySQL and PostgreSQL. The core weighs no more than 2.6 MB.

Re: Documenting FORMS

Posted: Tue May 09, 2017 6:49 pm
by FKlusmann
Thank you. I marked it [Solved] even though I don't like the solution.
Villeroy wrote: Base is not a database development suite.
It was your suggestion ("All this would be a perfect use case for a database with input forms, columns of distinct data types and clear table dimensions." - viewtopic.php?f=9&t=87069) that started me on Base. Thank you.

Re: Documenting FORMS

Posted: Wed May 10, 2017 2:12 pm
by Villeroy
FKlusmann wrote:Thank you. I marked it [Solved] even though I don't like the solution.
Villeroy wrote: Base is not a database development suite.
It was your suggestion ("All this would be a perfect use case for a database with input forms, columns of distinct data types and clear table dimensions." - viewtopic.php?f=9&t=87069) that started me on Base. Thank you.
With the help of your most simple database setup you now have the promised input forms, columns of distinct data types and clear table dimensions. As your project grows you may switch over to a more professional development environment where every change to an object can be documented automatically.

As long as you do your daily work with HSQL connected office documents you should improve one thing: Get your database out of the Base document. This will lower the risk of complete data loss significantly.
I've prepared a script to make this task as easy as possible: [Python] Macro to extract and reconnect embedded HSQLDB. Copy your database to a dedicated directory and load that copy, add the most recent HSQL driver from hsqldb.org to subdirectory "driver", extract the script to your profile folder and call Tools>Macros>Run>ExtractHSQL>Main
If you want your database to be accessible by many users simultaniously you may set up a little database server as a second step.

Re: Documenting FORMS

Posted: Thu May 11, 2017 12:10 am
by FKlusmann
Thank you!
I have more learning to do. I will
Villeroy wrote: .... switch over to a more professional development environment ... and ... Get your database out of the Base document.
Thank you for point this out to me.

Re: Documenting FORMS

Posted: Fri May 12, 2017 4:49 am
by FKlusmann
FKlusmann wrote: I have more learning to do. I will
Villeroy wrote: .... switch over to a more professional development environment ... and ... Get your database out of the Base document.
It seems that once the database is out of Base document one cannot edit the tables. So splitting the database during development does not appear to be a good idea.......

Any suggestions as to a "a more professional development environment" which some like me (small fixed retirement income) could afford?