Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgYou may find that the database being shipped with OpenOffice (ver.2) delights you as much as it has me. This page, and the others linked to it, can help you use it.
Forget any experiences you may have had with Adabas, which came with Star Office, the commercial version of Open Office 1. The Open Office Version 2 database, "Base", aka "ooBase", is unrelated. And remember that Open Office, including Base, is free! But don't let that fool you. It's not new. Big organizations, civil and governmental, are adopting it as their standard office suite... and saving million$.
There's more about ooBase in the main index to this material.
This page is "browser friendly". Make your browser window as wide as you want it. The text will flow nicely for you. It is easier to read in a narrow window.
Page contents © TK Boyd, Sheepdog Software ®, 2/06.
"A database" might be just a single table. But if you're not going to at least use a forms also, you might as well put the data in a spreadsheet.
A better use of the word "database" implies a collection of one or more tables (one can be fine) and queries, forms and reports designed to make accessing the data in those tables easy and idiot proof. In this sense, "the database" is the entity that contains those elements.
Generally, the tables, etc, in "a database" should all be concerned with a single task. Examples of "a task": Managing a directory of the people in an organization, inventorying assets, tracking orders and stock, phonebooks, school lists, etc.
While you are trying to improve your ooBase skills, you may find yourself with "a database", a collection of tables, etc, which has unrelated things in it. If you are just "playing around", just trying to see if you've understood something, then there's no need to start a new database each time you want to, say, make a table and a report drawing on it. Just be careful to give any such databases sensible names. Use names like "ScrappyExperiments". If in doing some of my tutorials you choose not to open a new database for each one, that will usually be okay. Just be a careful that there is no overlap in the names of tables, forms, etc. I have a database called "Tmp". It contains a truly awful mishmash of scraps of projects in it. But if I just want to set up a table to see what values can be put into a "BigInt" field, I can create that table within "Tmp" with no consequences. When you are building a set of tables, forms, etc to address some real need, it would be wise to put them all, and only them, in their own database. Starting a new database is not difficult; if in doubt, do it.
OpenOffice's database module, "Base" is a very satisfactory and capable answer for many people's needs. Partly in order to make it a servant of as many people as possible, a complexity was introduced that we won't benefit all of us, but which all of us must manage.
Base is capable of working with tables, queries, etc, originally created by other RDMSs. This will be a great boon to some people. Working with it's own tables, queries, etc, is always going to be more reliable, though.
The complexity we must manage is the system of "registering" the database which normally takes place at the time the database is created. It's not hard. More a distraction than a difficulty.
Don't, by the way, be alarmed by the question "Do you want your database registered with OpenOffice.org?" The registration process does not involve going online, it does not tell the providers of OpenOffice about you or your database, and it does not give them access to it.
What "registering" does do is to put an entry into a data structure maintained by the OpenOffice application on your computer. (The data structure is a bit like the infamous Registry run by Windows.... but is not part of it.)
And aside: Remember I told you at the top of this that it is different from most of the pages in this set of tutorials. If you just what to know "How do I do it?", and are growing impatient with this discourse, do try a different tutorial. But I've written the above, and what follows for a reason.
The data structure is shared by all of the OpenOffice modules. You don't need to, but if you wish, you can explore it via (from the menu) Tools | Options. After you've clicked those menu items, a window covering your options across the whole OpenOffice suite will open, with a tree in the left hand pane. OpenOffice.org Base is the name of a first level subdivision. Click on the + sign in front of it to see its sub-divisions. Click on the Databases branch to open a view of all registered databases.
A database called "Bibliography" is installed on your machine when you install OpenOffice. I'd be inclined to leave that, as it is probably used in various demonstrations bundled with OpenOffice.
Especially if you are a beginner like me, trying various things, the list of registered databases can grow.. and it can acquire some strange entries.
The first step towards keeping your sanity, throughout your computer work, not just with OpenOffice, is to use folders intelligently. Base respects your use of folders. A separate folder for your databases would be a good idea. You can put it somewhere beneath "My Documents", or in another place if you prefer. Putting it anywhere under "Program Files" is a Bad Idea. That part of your disc is for the programs that operate on your documents and data. Keep your creations separate.
Within your "My Databases" folder, you could create a new folder for each database. Then when you are finished with something, you just delete the folder. Close any files from it that are open first. In fact, ooBase "packages" all of the tables, folders, queries and reports of any database into a single file, so you may not need sub folders under the "My Databases" folder. Having a folder for each database can help, though, if you create machine readable output from the database, or machine readable notes on the database, e.g. a ooWriter document describing the fields in the database's tables.
But! Even if you delete a folder, the entry in OpenOffice's data structure's list of registered databases remains! You can (and should) delete it, using OpenOffice to access it.
You can get into a situation where different names in OpenOffice's data structure's list of registered databases refer to the same database. Probably best avoided.
If you thought you'd got rid of, say, FDB003 by (only) deleting it's folder, if you try again, and set up a "new" FDB003, then OpenOffice's data structure's list of registered databases will make up a name for the database, perhaps "FDB0031".
(By the way: I generally avoid creating folders with names like "My Databases". Not only do I find the name twee, but it is also hard to distinguish those which I've created myself, and those created by the system which may need to be respected. I'm lucky in my initials, "tkb". They don't seem to crop up in computer file names, so I can use names like "Databases- TKBs". Not the "Army speak": Noun first, then adjective. When I sort the contents of a folder by name, I don't want a whole bunch of "TKB... " entries. Also note that I have to eschew the possessive apostrophe, the name can't be in the correct form, "Databases- TKB's", as the apostrophe isn't legal in a file name.
Because of the need to register databases with the installation of OpenOffice on your machine, the following acquire complications. Just do things through OpenOffice, and all should be well.
All of the above can be done. Just be careful to do them correctly, via the tools built into OpenOffice. The parts of a database are interconnected, and when you make a change in one place, the ripples from that change must be taken care of.
In connection with all of this, I should mention that you will not see separate files on your hard disc for each table, form, query and report in your database. They... and other things... are all held in the database's ".ODB" file.
If you want to back up, say, a table, proceed as follows. It isn't as bad to do as it looks in the blow-by-blow account, which follows shortly. Don't overlook the "obvious", though: You can also back up the whole database, all of the tables, etc, just by using Windows (not ooBase) to make a copy of the ".ODB" file.
That's it! You have a copy of the table. Similar things can be done with forms, queries and reports.
The same techniques are useful for creating new tables, etc, from existing ones the copy/ paste, within OpenOffice that I've just described is the "Save As" mechanism here.
An aside: This is probably the spot to mention what you may need to be told: When you are actually working with your database, editing data, as opposed to setting the whole thing up, there is no "Save" in the sense that is normal in most computer applications. Each time you leave a record, ooBase tries to save that to your hard disk. The "Save" process is almost instantaneous. Only when (and every time!) you try to shut down the database, or a table in it, when you have changed what's on your screen for a record, but not left the record, are you asked "Don't you want to save the change you made?"
Lastly, there's one other way to protect your data you might want to consider. But I have to confess that, at the moment, I can't find how you achieve it! I suspect it will be a report, and I suspect that a quite simple line of SQL will achieve the same thing. I would be very surprised (and disappointed) if there is no way to "back up" your data via an export to .csv. What does that mean?
If you "export a table to csv", you are left with a plain text document with all of your data. This isn't a "perfect" backup in several respects... but sometimes it is better than none. And, as a plain text document, it is pretty robust. At worst, you can simply copy it by hand back into a new computer, one that replaces whatever was lost. Being able to get back to where you were before is, after all, the point of a backup!
This sort of backup is called "CSV" from the words Comma Separated Values.
Suppose your database held......
DOB Credit($) Name-Family Name-First 10/12/53 150 Bird Henry 22/12/51 250 Brown Lucy 05/05/55 120 Bach JohnA .csv file of that data might or might not include the headings. It would be very unlikely to hold information about the type of the data in each field. In any simple text editor or wordprocessor it would come up as follows. (Most spreadsheet programs include a way to import .csv data so that each field ends up in a separate column. ooCalc certainly does. There are related discussions in my ooBase tutorial about moving things from other RDBMSs to ooBase.)
10/12/53,150,Bird,Henry 22/12/51,250,Brown,Lucy 05/05/55,120,Bach,John
Don't let OpenOffice's data structure's list of registered databases be a cause for concern. I doubt you'll often think about it. It is there in the background, doing what it does, but it doesn't need to "talk" to you.
I hope one day to add a section to this page telling you how to "install" a new database (i.e. collection of tables, queries, forms, reports) on a machine. I presume it is not much more than copying the .odb file across to the new machine, and telling the ooBase on that machine where it is.
Remember the types of backups we've discussed:
That's it! I hope. Do feel free to contact me with advice on what questions you have been left with.
I dislike 'fancy' websites with more concern for a flashy appearance than for good content. For a pretty picture, I can go to an art gallery. Of course, an attractive site WITH content deserves praise... as long as that pretty face doesn't cost download time. In any case....
I am trying to present this material in a format which makes it easy for you to USE it. There are two aspects to that: The way it is split up, and the way it is posted. See the main index to this material for more information about the way it is split up, and the way it is posted.
PLEASE >>> Click here to visit editor's Sheepdog Software (tm) freeware, shareware pages <<< PLEASE
If you liked this ooBase tutorial, see the main index for information other help from the same author.
Editor's email address. Suggestions welcomed! - - - Want a site hosted, or email? I like 1&1's services.
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
. . . . . P a g e . . . E n d s . . . . .