![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
Yes - It's one at a time.
Hmm, a shame but plausible.
> And HSQL seems to require index names to be unique at the database level
> not the table level, is that right?Yes.
Isn't that a little... Non-standard?
Mark Stanton
One small step for mankind...
> Yes - It's one at a time.
Hmm, a shame but plausible.
> > And HSQL seems to require index names to be unique at the database level
> > not the table level, is that right?
>
> Yes.Isn't that a little... Non-standard?
Not really...Also, normally one would allow the tool to generate unique
index names - for example creating a FK relation will automatically
create required indexes, adding a PK to a table also.
And sorry if this is off track - but I just want to be sure that you are
referring to index names and not column names used for FK relationships.
Column names, even used in a FK are table specific not database (or
schema) specific.
So I can have
Table1 (t1PK, data1, data2)
Table2 (t2PK, data1, data2, t1PK)
Table2.t1PK will be indexed for a FK back to table1, the index created
will have unique name, but you need not create it, the create FK
statement will do so for you.
//drew
Am 29.02.2012 16:06, Mark Stanton wrote:
perhaps able to include some aspects of the
"spreadsheet paradigm" to data manipulation.That's an interesting thought.
What sorts of aspects do you have in mind?Mark Stanton
A database component without databases would be as interesting as a spreadsheet without references.
Minerals? Well, maybe in the larger ones, but English Chemistry - try this one.
This thread for the most part is exactly what should not be part of
this mailing list. The attitudes are horrible with very little said in a
positive way. Yes, why have Base? Why have a Base Guide? The person who
wrote a suggested outline for the Base Guide is among this group. With
this attitude, how could the outline be what it should be? Does it
suffer the same attitude problem? Besides, what purpose would it serve
given the comments about Base?
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.)
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.
OK, I have had my say. I will likely delete any replies that come
from this thread because I have seen people justify their actions in the
past threads. This is suppose to be a list to help others, and their
comments are not likely to do that. Besides, any replies to me need to
consist of references for getting the most from Base. Other than help in
learning more about how to use it, I don't need.
--Dan
Am 29.02.2012 18:15, Dan Lewis wrote:
This thread for the most part is exactly what should not be part of
this mailing list.
@Mark Stanton,
Would you please visit us at http://user.services.openoffice.org/en/forum/index.php next time?
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.)
You should read what people think after trying to work with Base in a user interface that suggests something very similar to MS Access. Everybody working through the ungrateful topics of Base support has to put things straight regarding what Base is and what it's not.
Drew Jensen is the single person who deserves all merits that some people (including me) found their way to do very productive things with this office suite's database connectivity.
Actually it is easy enough to access arbitrary table data beyond file format issues in order to make them appear in our office documents (once you got used to the fact that in most cases a "database document" may not contain any database). Slightly advanced users can prepare data sources and queries that are easy to use by the less capable users. Your letter template may use some Name-Address-ZIP-City query from a MySQL server and then you advise the end user to use another Name-Address-ZIP-City query from a plain text file you created this morning. The end user does not notice any difference between MySQL server and plain text when he reconnects his letter to another data source item.
Building a simple database application with data flowing from the office suite back to some connected database takes a conception of the database you are going to write to. This expert knowledge is beyond the scope of most users and it has nothing to do with ODF documents. It takes extremely complex tools to assist laymen in this effort. Even the expensive database suites can not do that much when you are not aware of some theoretical concepts.
First you have a relational database ready to use, then building some ODF input forms to edit the relational data is no black art. The minimum tools are availlable in Writer, Calc, Draw, Impress. They are very simple and "simple" is not the same as "easy". The design process involves user-ability rather than usability.
The resulting forms, reports and mail merge templates work very well for "my users" and me. "My users" refers to a group of rather computer illiterate professionals who need to write lots of info snippets into protocols, memos, inventories and serial letters collecting some 100 records per day in a small business network of 6 personal computers.
If LibreOffice would drop 90% of "Base", keeping the mere connectivity, the primitive query parser and ODF forms, we could still work with it in the same way as we do today. All the convenient but misleading rubbish built around the core functionality is obsolete.
Base should start again where OOo 2.0 left the well thought concept of OOo 1.x.
Wrapping portable databases in extensions rather than documents would solve all the data loss problems of the embedded database.
Reduce to the max!
Hi Drew,
Not really...Also, normally one would allow the tool to generate unique
index names - for example creating a FK relation will automatically
create required indexes, adding a PK to a table also.
I'm a little surprised. Although I've got over twenty years of database
development experience, it is largely in FoxPro (a dBase improvement),
although with a little of a few others. I've not seen, and certainly
wouldn't want, an insistence on automatically named indices.
And sorry if this is off track - but I just want to be sure that you are
referring to index names and not column names
Yes, I'm definitely talking about index names.
I took up Andreas' idea of importing my dbase-type files into an HSQL LO
database. It didn't realise the tables already had primary key fields. I
usually call these iId (as integer ID fields), and so want an index
(called iId) on each table. I can't do that in HSQL.
I know there's an idea that index names should include table names, which
would completely eradicate the issue, it's just that I don't agree 
It's a (perhaps) interesting discussion point rather than a problem
though.
Thanks for the info
Mark Stanton
One small step for mankind...
@Mark Stanton,
Would you please visit us at
http://user.services.openoffice.org/en/forum/index.php next time?
Coo, look at that! A busy Base forum.
I really much prefer stuff that arrives in my mailbox, but yes, I will visit
there. Thanks (again) Andreas.
Mark Stanton
One small step for mankind...
A database component without databases would be as interesting as a
spreadsheet without references.
That's true, but e-letter was talking about adding spreadsheet-type
facilities, not taking away database-type ones. In view of the
previous thread, and general experience, suggesting that spreadsheet
users sometimes want to make the jump to databases but find it
difficult, I'm interested in thoughts about facilities that would help
bridge that gap. Particularly as I'm starting to do some Base
development...
Cheers
Mark Stanton
One small step for mankind...
Hi
Yes, if you want to get involved with Base then OpenOffice has far better routes for getting in contact with people. TDF see Base as very very low priority so it refuses to give it even 1 mailing list let alone a whole forum. Still, it seems that here is the better place to actually get on with any work, such as documentation, faqs, coding or whatever area interests a person.
Regards from
Tom
Hi
The documentation appearing at
http://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Guide
The Faq at
https://wiki.documentfoundation.org/Faq#Base
(and the forum at OpenOffice, grrr) are having a major effect on Base.
It used to be almost impossible to get any answer at all about Base on this list. Now lots of people are giving opinions and sometimes even helpful advice. People don't come to this list to ask questions when everything runs smoothly!
Keep up the good work! Documentation is leading the way!
Thanks and regards from
Tom
Hi Dan,
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.)
On the contrary, I think you'll find that in the past (and I'm not referring to this thread) we have directed people to the OOo Base forums because that is where people with Base questions have found (at least partial, if not complete) answers. If we decide to ignore the existing information, advice and caveats, whilst it is still available and for the most part relevant, I feel we are just deluding ourselves.
OK, I have had my say. I will likely delete any replies that come
from this thread because I have seen people justify their actions in the
past threads. This is suppose to be a list to help others, and their
comments are not likely to do that. Besides, any replies to me need to
consist of references for getting the most from Base. Other than help in
learning more about how to use it, I don't need.
Dan, most of us who have commented here have worked, and still continue to work, with LO and databases in some form or another. However, we have learnt from much trial and error, late nights, gnashing of teeth and tearing of hair, some of us over a period of more than 10 years, that ultimately pragmatism must trump the day. Has that stopped me from starting the migration of the French Base FAQ to the English LO wiki ? Absolutely not.
On the otherhand, after more than 15 years of using StarOffice, then OpenOffice.org and now LibreOffice, majoritarily with database interaction I have absolutely no delusions about what Base can or can not do. That doesn't mean I've lost interest in it, but I'm perfectly willing to recognise its failings in comparison to those products to which it has always been touted as "equivalent", i.e. FileMakePro (even Apple's Bento is better than Base from a usability perspective), Lotus Approach, Access, and even some of the cloud DB/Form/Framework services now being offered for free in most cases. I call that realism, not negativism.
Since you mentioned references, I would say to anyone interested in Base, that they would do well to "start" by looking at the OOo Base forum :
http://user.services.openoffice.org/en/forum/viewforum.php?f=13&sid=73586058af5a5128696d435f0987e283
or even this one :
http://www.oooforum.org/forum/viewforum.phtml?f=10
Almost every and any question related to using Base has been posted there at some time. Yes, you have to trawl, yes you have to formulate a search query to find things there, but really, this mailing list is a far, far below what can be found on that forum in terms of breadth and depth.
Alex
Has that stopped me from
starting the migration of the French Base FAQ to the English LO wiki ?
Absolutely not.
Oho! So it hasn't! Between us we should get it done pretty quickly 
Mark Stanton
One small step for mankind...
I created a few databases but I found them unstable.... By that, I mean that things would simply stop working after an upgrade or after too much data had been added (by large I mean too many images so the dataset took many MB rather than too many records). The last time it happened, I just stopped using it rather than attempting to find and fix the issue. Toying with writing my own application in C++.
Hi
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.
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.
Regards from
Tom
Hi Andrew,
Was that instability with an "internal" HSQL database?
Mark Stanton
One small step for mankind...
Am 01.03.2012 22:19, Andrew Douglas Pitonyak wrote:
I created a few databases but I found them unstable.... By that, I mean
that things would simply stop working after an upgrade or after too much
data had been added (by large I mean too many images so the dataset took
many MB rather than too many records). The last time it happened, I just
stopped using it rather than attempting to find and fix the issue.
Toying with writing my own application in C++.
Images work well when you keep them in files and bind a picture control to a text field holding the relative URLs.
Writing a macro to fill a list box with file names and creation times is easy.
> >
> > Almost nothing has changed since then, except for fixing things that
> > should have been working right from the start 9 years ago.
> > The Base developers wasted too much time with useless wizards covering
> > no more than 30% of the program's capabilities and with a "self
> > contained database" document that is a caricature of a database
> > (unsafe,
> > unsecure, low featured and slow).
> > Base is best when you ignore most of its tools and helpers relying
> > entirely on your own skills and on the capabilities of the underlying
> > database driver.
> >
>
> Interesting; suggests that base exists just to answer the question by
> m$ fans: "where is the equivalent to acce$$?well, think what you want...though I will say this - one of the root
causes of Base's woes can be tied IMO to the first sentence in the
original design specification, to paraphrase from it "...because users
are too stupid to.....".Starting from the premise that users are stupid it is not surprising
that Base ended up the way it did.xoxo,
//drew
This thread for the most part is exactly what should not be part of
this mailing list. The attitudes are horrible with very little said in a
positive way. Yes, why have Base? Why have a Base Guide? The person who
wrote a suggested outline for the Base Guide is among this group. With
this attitude, how could the outline be what it should be? Does it
suffer the same attitude problem? Besides, what purpose would it serve
given the comments about Base?
These are fundamentally important questions to ask. You cannot realise
new paradigms/opportunities/etc. unless problems are looked at
differently.
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.
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.
OK, I have had my say. I will likely delete any replies that come
from this thread because I have seen people justify their actions in the
past threads. This is suppose to be a list to help others, and their
comments are not likely to do that. Besides, any replies to me need to
consist of references for getting the most from Base. Other than help in
learning more about how to use it, I don't need.
Your loss...
Hi E-letter
What Dan has already done for Base is pretty huge. However it is in an area that is undervalued within OpenSource communities. Allegedly it's one of the commonest blockers preventing increased uptake or at least it's one of the most commonly given excuses. People get all excited about coding and expect other areas to just happen by magic. Also what he has said has played out the way he predicted so it's not hurt him.
Regards from
Tom
<snip />
OK, I have had my say. I will likely delete any replies that come
from this thread because I have seen people justify their actions in the
past threads. This is suppose to be a list to help others, and their
comments are not likely to do that. Besides, any replies to me need to
consist of references for getting the most from Base. Other than help in
learning more about how to use it, I don't need.
Your loss...
I will be more specific:
I used the internal HSQL database for each proejct. Each database was sufficiently complex that I required a complex series of macros to fulfill my needs. For example:
Simple inventory that also stores images (could be a receipt, picture, whatever). So, I needed functionality that allowed for adding, extracting, deleting, and moving through the images. The entire system appeared to not be sufficiently robust to handle all of the image files as the size of the database grew. It is also possible that API changes were the issue. The only evidence that I had was that adding one more image caused corruption and the entire DB was no longer usable. I suspect that if I had used a better backend that could handle the size then I would not have experienced this particular problem. To put things into perspective, I was running a 64-bit system with 12 GB of RAM and the last working DB was 45MB in size.
I created a contact DB that required numerous macros to add entries that tracked things such as "yeah, I managed to get in touch with them on this date to this effect". I did not use the DB often, but it was very common for a new release to break the system and I had to change my macros so that things continued to function. Last time this happened (while tracking a different kind of inventory DB dealing with collectibles) I decided that enough was enough and I did not want to fix my macros anymore.
When I had a working system, I never had an issue loading Base and going directly to the tables. I was able, therefore, to manually copy all tables to a Calc document and then export to a CSV file (ignoring things such as binary data).
It should be noted that I spent a bunch of time just creating the macros to make the system work. For a complex system, Base still took a lot of time for me to accomplish complex things; for example, help and fill capability when I want the user to select from a human readable value but store the underlying ID.