Hi,

I raised the following points on the dba mail list and felt that I should 
record them here so that others could add comments if they wish.

I feel dBase whilst being a bit dated is still important as it provides a 
bridge from what people are doing now to the future.

Thanks for listening.

Kelvin

>>>>>>>>>>>>>>>>>>>>>>>>>

Hi,

Some time ago I asked whether the dBase file format would be available as an 
embedded data source.

The response I received was completely valid in that dBase is not unicode 
compliant.

However I would like to put forward to case for dBase also being included as 
an alternative embedded data source.

1. I have said alternative, so this means in addition to the hsqldb direction.

2. The user has a choice as to which embedded data source format to use

3. dBase is already an integral part of OO, so ruling it out on the basis of 
unicode requirements means in theory, it should be removed from all other 
parts of OO (such as the Bibliography) and this is unlikely to happen.

4. dBase does not require Java to be installed.

5. If the Report Writer is not being used, then Java is not required

6. If other document types are also included in the Base document, as raised 
in issue 33592, then complete applications could be developed without any 
dependency on Java.

7. By having two embedded data sources (dBase and hsqldb) right from square 
one, the developers are forced/encouraged to provide a more open design which 
would more easily allow for the incorporation of future embedded database 
options. (I know they will already do this, but the devil is always in the 
detail. Coding for two data source at the beginning means the detail has to be 
considered.)

8. Whilst dBase is not unicode compliant, there is no need to force it to be. 
For those requiring unicode compliance hsqldb could be used. For those who do 
not have the need for unicode compliance (and that is a very large part of the 
user base) dBase may well suit.

9. Providing dBase as an embedded data source would allow (except for Report 
Writer) the provision of Base documents with only the need for the 
OpenOffice.org download and nothing more.

10. If a user has dBase data in the Base document and the data can be 
exported, then the data is immediately useable by many other applications that 
have built in ability to read dBase files. This is not possible with hsqldb.

11. The addition of dozens of scaler functions to flat file queries, has made 
dBase more flexible in the coming OO2.0 release

12. As Base documents are single user by nature, the fact that dBase (when 
used within Ooo) is also single user, is not an issue.

13. dBase is the easiest of all database formats that I have found to use with 
OpenOffice.org in terms of designing tables and getting it to work. Almost 
every other data base source has been more difficult (may I add probably 
impossible for end users).

14. The use of dBase format because it already exists within OO and has 
significant development time to iron out bugs over the years, would 
potentially offer the project the most chance of a stable product in the time 
frame available.

15. dBase does lack the ability to join tables. Many simple end user data 
requirements such as simple lists do not need to join tables. (Again if joins 
are required then the user could move to hsqldb.)

16. Because almost everything is already in OOo to support the dBase format 
(or most likely being developed for hsqldb in terms of the approach to 
embedding data), then embedding dBase offers a higher probability of success 
both for the project and for end users.

17. There may be unforeseen problems with embedding hsqldb data within the OO2 
release time frame and the probability of success with embedding the known and 
simpler dBase data may be greater in the time frame available.

18. Making two data sources available as embedded data shows users and 
external developers that OO is significantly better and different from other 
products. OO offers choice, whereas other products don't. OO offers potential 
for future options, whereas other products don't.

19. Many users already use dBase as a data source for OpenOffice.org. For 
these users it is a minimal learning curve to use what they already know and 
to take advantage of the new Base document type. These users could immediately 
take their existing applications and build Base document applications. (Again 
this is probably dependent on issue 33592).

Further to my surprise it appears the new Base document does not provide the 
ability to import existing Forms and Reports. Given the ability to create 
Forms and Reports has been gutted from the general interface this now needs to 
be done within Base. The ability to import existing Forms and Reports needs to 
be provided.

20. At the moment users with dBase applications probably have files scattered. 
Using a Base document to bring all these together would make things neater 
(self contained) and more transportable.

21. If the Base document was able to take users existing applications and 
neatly bundle them, then the new Base feature could hit the ground running. At 
the moment the impact will be significantly less because it appears that 
everything has to be developed from scratch. Providing the ability to embed 
the data and import Forms, Reports and all existing documents relating that 
use the data would advance users from where they currently are.

In summary I feel dBase should be considered to provide one of two user 
selectable data formats for embedded data in the new Base document (the other 
being hsqldb as planned). It would allow OO to build upon the existing body of 
applications that have already been developed.

It would give users choice and visibly demonstrate the flexibility the 
developers are building into the product. This flexibility will be hidden with 
the use hsqldb only.

I know the user dBase as an embedded data source has been discarded in the 
past, but I thought I should put my thoughts forward.

I felt it was important to put forward my thoughts. I have said my piece and 
that is the best that I can do.

I may also be completely off track as it was only ever a future desire to 
include the data within the Base document if I recall the specs correctly. It 
simply appears the project may be progressing faster and thus the data may 
become embedded for OO2.0. If OO2.0 includes embedded data, then what I have 
said is relevant. If not then it is for some future release OO2.x.

Thanks again for all the hard work.

Kelvin