Marc Santhoff wrote:
Am Mittwoch, den 15.08.2007, 15:00 -0500 schrieb Barbara Duprey:
I have a database (embedded) with a table and a number of queries. When
I created the table by copying a table from another database, I
specified that a primary key should be created, so each record acquired
a unique number. Now I've gotten to a point where I want to add records.
Ideally, I could append them to the table from another source, properly
keyed. (I actually have the new records - unkeyed - as rows in Writer
tables right now.) But all I see as possible is entering each field of
each record, including specifying a key number, from scratch. Since
we're talking a couple of hundred records, that's not very attractive!
Is there a better way? Would updating from version 2.0.4 to the current
version (not yet 2.3, which I understand is making lots of changes in
Base) be of any use?
As the last time I answered my recommendation is OO.o-Calc.
In Writer use "tools - text <-> table" function to have the seperate
fields identifiable. Deselect "border" and use tabs as separators.
Copy the table to calc: Mark the complete table, select copy in Writer,
activate a (new) calc doc and paste to position "A1". This way you'll
get a nicely ordered table tranferable to base at last.
In Calc you can easily type in the last key+1 into the key column (that
you maybe need to insert first) and then use "edit - fill - series" to
have the keys inserted. Or grab the little black square with the mouse
and pull it downwards.
Afterwards the transfer to the table using F4 and drag&drop'ing the data
on the "tables" node is nearly the same as last time. Only instead of
creating a table you type in the target tables name and select "attach
data".
In OO.o 1.1.0 I'm using for having english menu names the last button is
labeled "create", but it inserts the data as expected.
If you have to do this task repeatedly, I'd suggest writing a macro.
HTH,
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Marc, as I mentioned the data was already in Writer tables (with
everything but the key). And I didn't actually use the via-Calc solution
last time, because of the data integrity issues I would have had . For
instance, some of the fields have (sort of} dates in them -- zero, one
or more text strings of the form m/dd or mm/dd in the same field (yes, I
know - messy, but preferable to multiple actual date fields for the
folks who get my output reports). Moving these into Calc requires that I
preface the ones that are alone in their fields, but only those, with a
single quote so Calc will allow them to be treated as text. Better than
having to retype everything, but still a royal pain. I'm sure a regular
expression could have handled this substitution, but I was fighting the
clock here and didn't have time to play around much. Anyway, that's why
I went the non-Calc route last time, as suggested in another response
(which mentioned possible data integrity issues, especially with dates
but implying that there might be other problems), and why I tried to
avoid it this time. Because my earlier updates (with the linked .dbf
file) had massively corrupted my data, I reverted to tables for the
second update cycle of the month, and entered the updates there. Then I
finally had some time to repair the data in the embedded database (about
twenty hours of work), and then update all the existing records. That's
where I was when I asked the question above -- I hadn't really worked
with what you said before, got scared off by the data integrity stuff.
So. After looking at your response here, I thought that maybe all I had
to do was add the key to my existing new data rows in the tables, get
them into the clipboard, and paste into the database table. That looked
as if it were going to work (got through the process to the field
mapping, which looked fine) but when I tried to Create, the SQL engine
reported an error (it apparently had generated a number of trailing
blank fields) and even when I said try anyway it did not perform any
updates.
At that point, I made the date changes to my data and copied into Calc,
then to the database table. As far as I can tell, that worked except for
one quirk - the first row of each copied spreadsheet segment did not get
copied.
I don't anticipate any more problems now, since I have a proper database
and can do my work in it as originally intended. But this has sure been
a painful experience, and I wouldn't want to see it happen to anybody
else. I'm hoping that the 2.3 Base will make this whole data-movement
issue work far more smoothly, but in the meanwhile, and for those who
don't jump on the upgrade, it's very cumbersome and error-prone.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
