![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Yeah, in retrospect, that is what I should have done. Would have avoided the DB too large issue as well. I am working (time permitting) on a C++ implementation in QT that does exactly this.
I don't understand any of the technicalities of what the devs are
saying about their process but Cor and Alex are saying completely
opposite sounding things so it sounds as though there must be a
bottle-neck somewhere.
I provided more clarification in another reply
It would be vastly more helpful to join in with the devs that are doing coding work for Base. According to Cor there are quite a few people doing such work. However according to Alex there are never many commits (or something). So, if one of the bottle-necks is just that someone is needed to do the equivalent of proof-reading and pushing through QA then it would be fantastic to do that rather than try to create soemothing new from scratch that benefits no-one else and that gets no help from anyone else either.
At the end of the day, it is an issue of time. I am behind on numerous pieces of documentation, and even when it works, it will take a significant investment in time to implement in Base and I still have the limitations of Base. As time is available, I am trying to find some other bugs that are very difficult for me to find. Off hand, it provides me more benefit in new knowledge gained (because it is something that I can use at work to earn money) if I build my own. It takes a bit more time, but I don't expect it to break with the next release (well, not as often anyway).
The better use of my time would have been to be purposeful of testing all of my DB applications against RCs so that I could have filed blockers. One issue, however, is that I cannot release the data contained in the DBs that I created.
What would most people who are new to Base think after reading the
negative comments about Base? Statements about how hard it is to learn
(comparing learning at least some of it to the difficulty of learning a
new language). No one seems to be able to give references that would
help. (No one has so far.)In previous other posts, there have been references to good OO
tutorial documents about base.
I created a frequently downloaded document that demonstrates numerous Macro methods using Base.
Recently there was a long thread that began with a problem with a
large spreadsheet. One of the early comments was that the data should
have been in a database. Now, it appears that that comment should have
been: you should be using a database but don't use Base. Strange very
little help was give as to how Calc could be used. So, it sounds like to
me that the advice seems to be: limit your use of Calc and DON'T USE
Base.What is wrong with telling someone not to use base??? The purpose of
free software is freedom to use other tools; noone said it had to be a
traditional office software product. I remember being advised by OO
users to use R for statistics; it was the appropriate advice at the
time.
Note that I did not advise against it, I merely stated why I don't use it much anymore.
Thank you. It doesn't have all the minerals but it does cut down on the number of terms marked misspelled. And that dictionary will be useful for other projects.
Jerry
Am 01.03.2012 23:02, Mark Stanton wrote:
Hi Andrew,
Was that instability with an "internal" HSQL database?
Mark Stanton
One small step for mankind...
The .odb file claims to be a document but in fact it is an extension. When you open the file and then open one of its objects, the embedded HSQLDB will be extracted to the temporary office directory so it works exactly like an external database in cached mode.
If your form/report/other office component crashes during this installation process, the whole backend database is lost. Similar problem when you close the "document" and something weird happens during the repackaging. Sometimes you can reconstruct the backend from the temporary files.
According to the forums, the total loss of an embedded HSQLDB happens quite often. This flaw is the total knock out for any program that claims to be a database.
I used to use one fairly complex embedded HSQLDB for a period of 18 months. The development time was a full weekend for the backend and simple forms plus another weekend for the advanced forms. I worked with it one hour per work day beeing the one and only operator of that thing. It grew up to a document size of 5 MB. I made a backup before every session but this particular file always worked reliably and never crashed. I did not need any macros at all since I know some SQL tricks and I am not miffed because of one click more than necessary.
So yes, I made my own positive experience with that "embedded HSQL". Nevertheless setting up a database server in order to work with "the real thing" is such a tiny effort and it can give so much more safety, security and performance that I do not recommend the embedded version.
Hi Mark,
Was that instability with an "internal" HSQL database?
The instability issues of "internal" HSQLDB databases within ODB files is well documented on the OOo Forum, along with suggestions for avoiding or minimizing those issues.
The basic line of reasoning goes : "switch to a non-integrated db backend, be it hsqldb (file mode or client/server mode), H2, SQLite or some other db engine", with the reasoning being that your data is more precious than any form or query or pipe dream you could ever want in an ODB file.
And for the benefit of Dan, a documented link of how to do this :
http://www.oooforum.org/forum/viewtopic.phtml?t=97522
Alex
:-)) In between two cups of coffee in the morning or late at night, it is amazing what can be done when one is otherwise bored... 
Alex
Am 29.02.2012 14:36, e-letter wrote:
Interesting; suggests that base exists just to answer the question by
m$ fans: "where is the equivalent to acce$$?
Right, at a first glance it is nothing but Access mimicry.
Maybe base should be removed from LO entirely and a separate database
product be developed, perhaps able to include some aspects of the
"spreadsheet paradigm" to data manipulation.
The "spreadsheet paradigm" does not work in a database. The purpose is to be compatible with *any* of the commonly used SQL servers while treating tabular files in the context of the database paradigm. For instance, Base reads a spreadsheet so its list content can be used as if it were a structured database. It is not intended to be the other way round.
Apart from this, nothing will ever stop people using the calculator to organize their data in crude ways. They do not follow any design concepts and the spreadsheet allows them to dump their stuff any way they want. So be it.
All the connectable external database servers do not provide anything like a "spreadsheet paradigm". The functionality of a database is completely different to spreadsheets. It is analogue to bitmaps and vector graphic.
Something like the MS Works database rolls completely on its own proprietary rails. The development of such a component would be expensive and the result would not be as useful as the current database connectivity.
Just drop these "easy peasy" database development toys. There is no need to create databases from scratch. Other programs do this perfectly well and the resulting structures can be connected to this office suite. Except for the report generators, the database toys are obsolete. Report generation is a unidirectional process which yields ODF documents.
Form design is more like writing a program for an alleged end user. The program needs to read from and write to the underlying database. This is where wizard technology falls way too short unless you invest extreme amounts of development resources.
The simple tools that are provided for manual from design are very well suited but unknown and undocumented.
I created a frequently downloaded document that demonstrates numerous
Macro methods using Base.
And very good it is too!
Mark Stanton
One small step for mankind...
Am 02.03.2012 04:25, Andrew Douglas Pitonyak wrote:
What is wrong with telling someone not to use base??? The purpose of
free software is freedom to use other tools; noone said it had to be a
traditional office software product. I remember being advised by OO
users to use R for statistics; it was the appropriate advice at the
time.Note that I did not advise against it, I merely stated why I don't use
it much anymore.
Nor did I. Base is our most used component. We run 4 PCs where at least one Base form is open all the time during the work day.
And of course we use Base together with a free database server since the freedom of use includes the obediance to standardized interfaces.
We have no spreadsheet nor letter template that is not bound to a data source of some kind.
Base saves us a lot of money because we don't have to buy all the additional modules of our licensed software.
Base has a lot of most prominently shown but most obsolete wizard tools which are not required to work productively with databases. Quite often these wizards do the wrong thing or they do the right thing wrongly.
So I recommend not to use the most prominently shown parts of Base.
Using the manual desingn tools together with the command line is by far more productive if you know what needs to be done.
This is what this whole thread is about. Letting Mark Stanton build a Writer report based on alleged relations between his dBase tables although the built-in driver does not support relations, thus it can not merge the contents of different tables.
I wonder how many of the mineral type of words are in my largest dictionary[s]? It[they] has[have] over 638,000 words in it.
http://libreoffice-na.us/English-3.4-installs/dictionary.html#english
My dictionaries start with "kpp" in this list of "English" dictionaries.
Well, if I had a typed source of all of the needed words, in a list or a document that can be converted to a list, then it is easy to add them to an existing dictionary or create one specifically for it.
I would not trust me typing skills to type up a list of minerals from a printed source. So, having a "text" document for the computer to convert to a list of words is not hard. BUT if the words are to go in a spelling list, then they must be spelled correctly.
If I had a trusted source for the words, I would add them to a "specialized" list for science related words.
Hi 
Blimey! That looks like more than 2 cups of coffee each!
http://wiki.documentfoundation.org/Faq#Base
Regards from
Tom
Hi
You know you ca right-click on a word that has a red-wriggle and "Add to dictionary"? Then later in the same document and any future documents that word would be accepted.
The tricky bit would be keeping a copy of your modified dictionary backed-up somewhere. if you can work out how to do that and also send Tim (webmaster@krackedpress) a copy then he could probably work with that to create a specialist dictionary for chemicals and minerals.
I think you can have more than one dictionary loaded at a time and the "Add to dictionary" looks like it is set-up to offer a choice of dictionaries to add the word to. I guess it would be really great for most of us to start our own dictionaries of technical words for whichever area we work in but i haven't a clue how to do that either so i just add to the standard dictionary each time.
Regards from
Tom
That "add to word list" type of thing is what I did to get some of the words I used for these emails to include in my next version[s] of my big word list dictionaries.
I think there was about 800 +/- to 1,000 +/- words going to be added to each list. I have to do some work on the dictionaries to get them ready for publication. Actually I cannot find the updated lists. They are not in my "word list folder" so I have to rebuild them, again, or I just forgot where that folder really is.
Been really busy, so I have not had time in the last months to do the work needed. Rebuilding them is running the word list files and the new word list[s] through a package and then changing the .oxt files. That is 11 current ones, plus one new one. The 638K lists will go to 639K and there will be one en_US that is over 700K as the new one.
So yes, if someone has a text file of a list of words that are the CORRECT spelling, I can make a modified dictionary .oxt file to include those words, either as a separate .dic file in the .oxt file or included in the en_US, en_CA, or en_GB .dic files.
I could have a 1 million word list, but they are words that have alternative and rare spellings for many words, and they are not completely verified. Now having mineral names as will as other science names/terms [including medical and chemical words] would be good to have for a larger word list. I think the planned 700K+ list does have US medical and chemistry words in it.
Mark Stanton <mark <at> vowleyfarm.co.uk> writes:
When I select the dBase connector it seems to say that queries cannot
contain more than one table.Tekll me it's not true...
Mark Stanton
One small step for mankind...
Mark, it IS NOT TRUE. I have routinely used ~25 tables, and run queries
using 3 or more tables. I find it most useful to structure my queries using
the SQL command line rather than the "wizard", although it can be done using
the "wizard" also. I am running Linux, and I use PostgreSQL for my database
engine, and the Java JDBC Driver.
An example two table query is:
SELECT DISTINCT "VenIndLoc".*, "Products".* FROM
"All_IPO-wi_Industry_Location" AS "VenIndLoc", "wms"."Products" AS
"Products" WHERE "VenIndLoc"."CO_NAME" = "Products"."COMPANY" ORDER BY
"VenIndLoc"."CO_NAME" ASC, "VenIndLoc"."INVEST_NO" DESC
where the two tables used are "VenIndLoc" and "Products".
Hope that helps.
Cheers,
--Bill
Mark Stanton <mark <at> vowleyfarm.co.uk> writes:
When I select the dBase connector it seems to say that queries cannot
contain more than one table.Tekll me it's not true...
Mark Stanton
One small step for mankind...
Sorry but William is wrong. The dBase connector does not support relational databases. Besides dBase uses its own method of defining relationships that is not the standard use by most database engines. The dBase connector is not able to provide Base with the information needed to use the dBase's method when creating a query.
--Dan
Hi Dan,
Thanks, yes I know William was mistaken. My post was slightly
tongue-in-cheek (& long enough ago now that actually I'd forgotten
about it ).
My guess is that the dBase connection only supports one file because
it's a file connection not a process connection, there's no database
engine running for the connector to ask to do the complicated work.
Mark Stanton
One small step for mankind...