Barbara Duprey wrote:
Tim Deaton wrote:
Barbara Duprey wrote:
I doubt that separating Base would have much in the way of negative
consequences -- it sort of follows the pattern that MS chose in
making Access a separate product or part of MS Office Pro rather
than the basic package. Since, as I understand it, no other
components depend on Base (unlike the interdependencies among the
others for common code), and it would decrease the size of the
primary download, this might be worth looking into. A couple of
other possible advantages would be the ability to update Base on a
different schedule with regard to the others, which could simplify
testing for both packages, and the opportunity to package the major
extensions as optional parts of the installation with more
visibility into their capabilities. I wouldn't expect the Base user
community to be upset by having a separate download for it.
I haven't yet used Base, tho I hope to one day replace Access97 with
it. That's why I follow these discussions.
I'd have no problem with the idea of offering Base the way Access is
- both as a separate module and as an optional part of OpenOffice. I
DO want it to be able to interact well with Calc (and with Excel) in
terms of being able to read, import and export table-style data
to/from those spreadsheets. (I'm not familiar enough to know how
well it currently does those things.)
-- Tim Deaton
Currently, this kind of transfer works through the OS clipboard, and
there are a few things that could be smoother. You can get the job
done, though. I'm in the process of trying to come up with some kind
of UI definition for Import/Export functions, it'll appear in the OOo
wiki for comment/modification. Feel free to send me any ideas of how
you'd like it to work, either on or off this list!
I'm thinking about the way Access interacts with Excel. It can link
directly to a sheet within an Excel workbook, so long as the sheet is
organized as a table. In the linking process, you tell Access which
spreadsheet to open. It then displays the list of worksheets and you
pick the right one. Then you tell it whether the first row contains the
fieldnames or not. It scans the data and makes its own decisions as to
what kind of data each field is (numeric, text, etc). Once that's done,
the sheet is treated like an unindexed table. You can edit, add, and
delete records, and you can use the table in a query or report. The
lack of an index creates limitations as to how the data can be used, but
it makes creating useful reports of the Excel data much easier.
It also makes it very easy to import the data into a real database table
- which is what I mainly did. I got data daily in an Excel format and
cleaned it up if need be so that it fit into the predefined Excel
table. I then give that sheet the name that the Access link would be
looking for (while the Access database is closed). Next, I opened my
Access database and ran a set of queries. The first query in the
sequence used various functions to format the data into the data-types
that Access understood. That and subsequent queries in the sequence
might do other massaging to make the data more useful. Then the last
query in the sequence would append the data to an existing Access table
that also had a field with an 'autonumber' data type as part of its
index - thus insuring that the index would see each new record as unique.
-- Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
