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


On 08/08/14 16:23, Paul wrote:
Hi Joel,

In addition to the below, you'll need to think about what database you
want to use. With Base, you can use the built-in HSQLDB, but from all
reports you really don't want to do that. I'd suggest setting up
something like PostgreSQL or MariaDB on your machine, and using that
with Base as the frontend.

I'm not sure how much you know about this stuff or how closely you've
been following the discussions on this list regarding Base database
backends, but it isn't really that hard from what I gather, and it's
best to start off with a good setup, although you can opt to start off
simply with the builtin backend and migrate later, but that will mean a
little more work down the line.

On Fri, 8 Aug 2014 13:04:18 -0700
Joel Madero <jmadero.dev@gmail.com> wrote:

when I make the form to enter new data (ie. a new read book) can it be
designed to where it searches the current books in Books table and
then if, and only if, it doesn't find a match (based on author + book
title), it starts a new form for me to enter new data?

This probably requires a macro in Base, so I'm not sure exactly how
complicated this will get, but yes, it should be able to do this. With
constraints on the database (like a unique key on the author and
title) it should prevent you actually entering duplicate data (barring
a misspelling), but you of course want to know about that situation
before filling in the whole form, so probably a macro, or a button to
check the table for the book, before you continue filling in the form.

It should also be easy enough to make a search screen to find books in
the table, which is probably something you want anyway. So you could do
this before entering books that might already be in there, but that is
then a two step process, instead of the more straightforward process as
described above, although probably slightly simpler to set up.

This is something I would leave out for now, just get it working first,
then add these sorts of helpful things once the basic design is working.


For a series, is there a way for me to do like "enter a series" and
then it would prompt  ("how many books in this series") and when I
put in 5, it would then auto fill author + series name, so all I have
to do is enter book titles for the 5 books and all 5 would be added
to the Books table?

This should be doable. I'm not sure exactly how to do it in Base, but it
is probably simplest with something like two entry forms, one that
just enters a single book, and one that takes an author and series name,
but a list of titles. Or maybe just a button on the entry form that says
"Add next in series", that would re-bring up the entry form with those
fields prepopulated.

Again, probably just get a single book entry screen going first, then
add or adapt it to do series.


Reading books twice - I don't do this often, but when I do, I expect
the pages to count twice. Best way to accomplish this is to have
another field called "Count" and then page count would be Page Count
* Count (# of times read)?

Best to call this something like ReadCount. You want your names to be
descriptive, without being horrendously long.

So the table would have a PageCount and a ReadCount, and any report
that you design would have a field called ReadPageCount, that would
show PageCount * ReadCount, but it wouldn't be stored in the database
(no need, and it would again be a case of duplication).


I'm getting excited about this as I've come up with another cool idea
that might be easy. I'm going to link books to the library, so for
"next book in series" would be a link that I could click and easily
put on hold at the library :) I think that this would be both awesome
and relatively easy (assuming the library has a standard method of
searching which I suspect it does).

You would need to have some way of interfacing with the library system,
but yes, assuming they have such a thing, it can be done. Again, I'm
unsure of the limits with Base, but it is probably doable through a
macro. This might be a bit advanced, I'm not sure. Best to leave it
till all the rest is working :)


Paul


The BASE file is actually a zip file that contains the individual files
for each table in the database.  If you use the built in HSQLDB while
you develop your database you can later open the BASE file in an archive
manager of your choosing and extract those tables into an external HSQLDB.

What I'm getting to here is that you don't have to set up a separate
back end DB while you are developing your database.  You can use local
tables for all that until you get the database to behave the way you
want it to.  Only then will you have to consider splitting your DB into
a front end that contains all the forms, reports, and Basic code, and a
back end that contains the tables that hold your data.

When you're ready to split your DB, probably months from now, I can find
the instructions for you.

-- 
    _
   °v°
  /(_)\
   ^ ^  Mark LaPierre
Registered Linux user No #267004
https://linuxcounter.net/
****

-- 
To unsubscribe e-mail to: users+unsubscribe@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.