Specifically, LO uses Writer to create forms for Base. Seems to me
that what Writer creates is "text documents". If not, then what is a
Base form? Is it a document? If so, what kind?
--Dan
Yes - it is a standard ODT document.
The differences the user sees at run time, per what is and is not
available in UI and what parameters are pre-loaded is done by code,
triggered when the form is loaded from within an ODB file.
Depending on how the document is opened, for editing or for data entry,
it is treated as either a OTT or ODT.
Report made with the default Report Wizard (meaning when there is no
Report Builder installed) are also standard ODT files.
Report Builder report definitions are not standard ODT files they are
RPT files, which is a variant of the ODT file structure. When a Report
Builder definition is used to generate an actual report then this output
is either a standard ODT or ODS document.
I hope that helps,
//drew
Hi 
Blimey. i hadn't really appreciated that about Base. Sounds like it might be reasonably easy to let people have access to some of the data in the database while still keeping other data confidential. So different users could have access to different fields.
These Odt's and .Rpt's can appear to exist outside Base? So people just see an Odt file without really being aware they are using a database?
Regards from
Tom
Hi
Blimey. i hadn't really appreciated that about Base. Sounds like it might be reasonably easy to let people have access to some of the data in the database while still keeping other data confidential. So different users could have access to different fields.These Odt's and .Rpt's can appear to exist outside Base? So people just see an Odt file without really being aware they are using a database?
yes and no.
In the case of a form developed within a Base file - if you open it in
data entry mode and save it as a stand alone text document it will loose
all links back to the datasource - these can be fixed up of course.
This then brings up another difference, in a stand alone ODT/ODS file
embedded dataform components may be attached to multiple datasources.
This is disallowed when embedded in an ODB, all dataform components must
connect to the same datasource.
In the case of a Report Wizard (no Report Builder installed) created
file, saving it as a stand alone ODT file will create ONLY a static
report - in other words the values will be static. There is mechanism
for running the report again - though all the information required to do
so is contained within a set of hidden controls in the document, the
code to execute them as needed is not available outside of the Base
module, nor is there an api for calling it directly.
In the case of a RPT definition created with Report Builder, there is no
way to work with that outside of the Report Builder extension.
In the case of scripting there are also some differences.
A stand alone ODT/ODS may have scripts embedded within in the document,
this is not allowed when the document is itself embedded in an ODB file,
rather embedded scripts must be stored at the ODB level. If you have any
scripts that make use of the ThisDatabase pseudo variable those would
break as this variable is, naturally, only valid when the script is
loaded from an ODB file.
//drew
Hi
Hmmm, didn't quite understand all that. Does it reduce down to
Forms = Yes, but sometimes have to fix datasource links
Reports = No
Both have problems with some scripts, some of which can be sorted but not trivially. Both can be used to show static data, such as the final result of a mail-merged document/spreadsheet
Regards from
Tom
Hi
Hmmm, didn't quite understand all that. Does it reduce down toForms = Yes, but sometimes have to fix datasource links
Reports = No
Both have problems with some scripts, some of which can be sorted but not trivially. Both can be used to show static data, such as the final result of a mail-merged document/spreadsheet
Regards from
Bonjour Tom,
It's best IMO to keep this in mind.
There is nothing a user can do in Base, disregarding the Report Builder
extension, that can not be done with stand alone text/calc documents.
The vast majority of functionality existed in the suite prior to the
development of Base. The exceptions being, the embedded HSQLdb, some of
the user admin (never fully implemented) functions and the Report
Builder extension. [might of missed another one or two, but that would
be all]
Data connectors work just as well with stand alone text/calc documents
as they do with Base files.
All of that functionality is IIRC already covered in existing user
documentation, with regards to the data forms in text documents.
//drew
Hi
Ahhh, so the powerful bit is LibreOffice as a whole rather than Base. Base 'just' provides
1. A convenient container to keep things together
2. Something that ostensibly looks a bit like Access
I don't know that i agree that. From the sidelines it looks as though Base nearly offers far more flexibility (or at least far more easily) than Access. The main problems appear to be the "nearly" part of that. The scalability aspect of 'just' switching back-ends but keeping all the front-end the same is one huge advantage.Â
Regards from
Tom