(Comments in message)
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Barbara,
Are you (or is anybody else lurking here) aware of an issue for this? If
not - Barbara or Marc, care to submit one? I mean, there should be a
direct way, shouldn't it?
I'd be glad to submit an issue if there isn't one. My idea of how it
should work would extend the kind of data movement that can be done in
Writer (and I guess Calc) where you can select and copy a rectangular
portion of a cell grid, select the top left corner of the destination
cell grid, and paste. That would extend the current capability to use
copy to create/append. (It could even include generating new data base
records as needed if there is an auto-increment value for the key
field.) It would work in queries as well as tables. I love the way paste
works in Writer, it's very intuitive and makes short work of things
I've often had trouble with in MS Word (haven't tried any particularly
recent versions of that, so I don't know if you still have to select an
exactly equivalent area in the destination to be able to paste, but that
was necessary in all the versions I've worked with).
Do you folks agree that this would be a reasonable request? I obviously
haven't thought it through all the way, but I could provide examples of
the kinds of things I'd like to see. Basically, I'd like anything that
looks like a table in Writer, Calc, and Base to allow data interchange.
I've written a lot of User Guide type documentation, I could even work
up some kind of draft of one for this.
I admit my original RFI (request for issue :) was more about the
inability to fill in a PK field (that is: copy a data range to a new
table, let Base create a PK, then copy a homogenous range to the same
table -> Base should fill in the PK values, as good as possible. If I
understood it right (I cross-read this thread only :-\), this was the
original problem.)
Yes, that was the specific question (let's call it Issue 1). In this
case, it would be complicated by the fact that Base did not define the
PK it generated for the original .dbf import as auto-increment. So as
things stand now, the first db table would probably have to be copied to
create a second that was defined as really intended, before Base would
know the pattern to use. I should also have changed the lengths of some
fields, which were picked up using the maximum length that currently
existed in the field and therefore could not be increased with new data
-- in my case, additional "dates" in an expanding status field, or
comments in a description. I'd have thought that "VARCHAR" would
automatically expand as needed up to at least 255, but it doesn't, and
the field definitions cannot be modified in place. The option is
presented to delete the field and append a new one as redefined, but
that discards all the data. (Issue 2).
Your idea sounds somewhat unusual for a database (in which situations,
for instance, would you want to copy a rectangular portion to a location
starting at another column? How often, really, does one have data where
this makes sense?). Or is this just me?
A brief description of how I'd get into this has to do with one person
(me) controlling the database, while other people collect additional
data to go into it. These people are neither familiar with databases nor
authorized to update the master, but it would be nice if they could work
in a table or spreadsheet (depending on their preference), and I could
copy the data as needed from there. One thing that would interfere with
this is described in the thread about updating from a query with a join
(not currently possible, no apparent plan; existing issue cited in that
thread). Another is that existing data copy capabilities into Base
follow different rules for Writer tables and Calc spreadsheets (and
maybe different again for other formats of text documents, spreadsheets,
and databases). Let's call the sometimes-missing first row Issue 3; and
Issue 4 that I've recently identified is that copies from Writer tables
into text fields add leading and trailing blanks, while those from Calc
do not. (That one's been fun for my normalized version of the database.)
Also, in preparing this material to go to these people it would be nice
if I could copy a rectangular block from an existing database table or
query (Issue 5). As is, I often have to create a query with the specific
subset I need. Once I have a query that's as close as I can get, I copy
all its data, paste-special into an empty portion of the destination
document (haven't tried this with Calc, just Writer), delete/reformat
columns as required, copy, and paste into my destination table. Since
Base seems to "like" Calc better, the transfers might be smoother there
-- but I'd expect problems with my "dates" again.
While I'm at it, I might look for something about the
much-less-than-helpful error messages when the current create/append
logic hits a snag. May have been fixed since 2.0.4, but if not ....
Ah, please do. I *know* our error messages are terrible way too often,
and I'd like to correct this wherever possible (Unfortunately,
translating low level error conditions into human-readable, high-level
error messages is one of the higher arts of programming :).
OK, Issue 6. When copies fail, they don't provide any info about where
they hit the snag. For example, I had a Writer table of about 3000
entries that established my Addresses table, but three of the keys had
typos that violated uniqueness. The message just indicated that there
was at least one uniqueness violation somewhere in the data; it would
have been very helpful if the error message at least included the
information about the record number from the source where it was getting
into trouble (a presentation of at least the first badly-behaved record
would be nice, but I can see where that would be difficult if it's
disobeying the formats - maybe a last-successful-record display?). And
those leading and trailing blanks caused data length violations for the
fields that really are known to be short, when I tried to define the
fields as the correct length, but I didn't know that was why the copy
was failing at the time.
Thanks & Ciao
Frank
Thank you! It's great to have a way to talk to real live people about
this stuff. I don't know how much of this is already dealt with in
current or planned releases, or has issues I should vote for, or
whatever - haven't really gotten into the best way to do the searches.
Barbara
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
