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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
