Marc Santhoff wrote:
Am Freitag, den 17.08.2007, 11:33 -0500 schrieb Barbara Duprey:
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.
Now that you name it I remember.
One remark: The field format should be no issue here, because the target
table already does exist and OO.o is doing it's best to get the
conversion for known targets right. I actually did what I was suggesting
and had no problems. Date values have involved and the were written in
proper localized form (17.08.2007 for today in DE) and it worked fine.
This will not solve the decision problem for your special date format,
though.
[...]
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.
Maybe this is special to OO.o V2.x, I didn't see such error or added
blank fields.
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.
Funny, I've tried your way (copying the table from writer via clipboard)
and the first row of data got lost. Using calc all data was transferred.
Maybe I can get my hands on OO.o 2.x later tis weekend ...
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.
I feel with you. ;)
If the updates of your data are regularly done this really is a pain. A
scripting solution or something else fitting the environment should be
used then. Maybe simply exporting from the writer doc to csv and
importing directly into base (if possible, should be) will do.
Marc
Thanks so much for all your help, I really appreciate it. From this
point on, I think I'll be OK -- I'll do the updating of existing records
right in the database, and I'll use Calc to enter all the new ones
easily, then copy over to Base. Because of the data-fill capabilities,
that will be the easiest way to do it, and I'll just need Writer tables
for my output reports, with no need to import anything from them.
Think I can start breathing again now!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
