Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index




Tom Davies wrote:
Hi :)
I was forgetting the Report Builder wizard but i thought it was best to avoid using that anyway?
I avoid Oracle Report Builder too! For me, it is a basket case and needs a lot of work.
Your division of Back-end into 2 parts; data and server made a lot of sense. Using the word "Client" instead of "Front-end" also makes sense and is probably more familiar to a lot of people now anyway as we hear the terms "email client" rather than "email front-end" and such.
These are the terms that I have always used. However, I have seen the *-end terms used also. But IMHO client - server seems more logical and informative of what they do, than front-end - back-end.
Are you offering to review the Base Guide that is in ODFAuthors? or could you email Dan to see what he suggests? There might be some good reason why he has gone a more generic route with the guide and perhaps is saving up the divisions for another chapter or a guide aimed at a different level of users.
Well, I could offer suggestions, but I am not the writer, so I could only suggest. As you say, there may be other reasons for the current manual references. However, I have seen postings on this forum from confused novice users, who could have benefited by additional background information on the database "system". I realize that with so many possible servers out there, writing a manual section on each one and how it fits into the Base system could be daunting. I have run across many other documents relating to configuring MySQL and Base, but there are all the other servers that could use some documentation regarding how to set them up with Base. That setup documentation is currently lacking in my view. Maybe the recent work of translating the German handbook will correct that. But the users surely need more documentation on connecting to servers other than the bundled default HSQLDB internal server, which does not have a good reputation with some users. In that light, I would also suggest some words to the effect that "...here is the embedded HSQLDB, but if you want a serious database server connection, we recommend using x, y or z. Now here is how you connect them..." Documentation on connecting Base to external servers may be at least a chapter in itself, with each server as a separate section in that chapter so the user could go to that section and perform a particular process to connect it. The users should not be required to do all the time-consuming research and study to find how to connect his/her preferred server to Base. I could offer some words on MySQL, but I have no experience with the other servers. I just realized that the scope expands to include processes for the different operating systems that LO and the different servers can run under! That would make writing it even more daunting. I can see now why it has not been attempted to date. But I think it should still be done for the user's and the future of Base's sake.
Regards from
Tom :)
<snip>
Regards,
Girvin Herr


--
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.