Frank Schönheit - Sun Microsystems Germany wrote:
Hi Barbara,
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.
This would be an RFE (request for enhancement) in IZ, to have an option
to create the PK as auto-increment, if possible.
OK, I'll do that.
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.
Or you could change the type of the auto-generated PK to be an auto-inc
value.
Not directly - at least in 2.0.4, Base won't allow redefinition of a
field, but apparently in 3.0 it will.
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).
okay, copying a sub-range of a table/query to somewhere else is
something I'd easily agree is useful.
This is probably the heart of the whole thing. Sounds like a pretty deep
change, though, since the whole current structure seems to be built
around confining all edits to a single field in a single record at any
given time. No Find and Replace, for instance, which would have been a
great help in dealing with those leading and trailing blanks. (Still
haven't really tackled that one, I'm just putting the extra blanks into
the join key field in new records; that's the only one that really matters.)
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
I see. So you need this because Base itself lacks certain editing
capabilities ...
Right - most of them, as described above, because of the single-field
thing. Maybe the new Report capabilities will help out here, though I
still will need to tweak the data or redesign things to include one or
more Notes fields I can leave out for some of the reports (the better
option, though that's an exercise to tackle later). I inherited the
basic structure from the original Word table-based process, which
discarded all the history each month.
OK, Issue 6. When copies fail, they don't provide any info about where
they hit the snag.
Ah yes, this one ... I agree this is (and has always been) annoying.
I'd say you create a small sample .ods, a small sample .odb (with data
where copying will fail at some record inbetween), a short description
what to do - and put this into IssueZilla :)
Thanks & Ciao
Frank
Will do, thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
