Apache OpenOffice (AOO) Bugzilla – Issue 9899
Mail merge from Calc or Excel - embedded fields not updating on refresh
Last modified: 2011-03-07 09:12:57 UTC
Open word processor, connect to spreadsheet datasource -- I was using Calc and tested on Excel too. Also have the spreadsheet open, or subsequently open it, and make a change and save it. Refreshing the data in he word processor does not show the update in data fields previewer. Merge prints out wrong information. Even when soffice was entirely closed and reopened, the data was still incorrect in the merge. This happened on 643C and 1.0.1.
HI->MSC: What is the rule for the update.
Hi, I can reproduce it. The problem is the connection pooling if you turn of the connection pooling under TOOLS/OPTIONS/DATASOURCE/CONNECTION POOLING the data are refreshed when you disconnect from the datasource. Bye Marc
Hi, something for you because you are responcible for the spreadsheet driver. The driver has to check if the data has changed. You don't need a mail merge to reproduce this bug, just create a calc file and use this file as a datasource. Then change some data in the calc file, the changes are not displayed in the datasource. Bye Marc
> Even when soffice was entirely closed and reopened, the data was > still incorrect in the merge. This happened on 643C and 1.0.1. I think this is issue 8174. Niklas, the only solution which comes to my mind is that the Calc driver should recognize changes in the underlying file, and reload if necessary. This may need carefull examination: First it can be done upon re-creation of a table only (existing tables should not be reloaded of course), and second it may need special handling for the case where other tables are still open. I think the main question here is whether tables in a Calc connection should live as long as the connection does. For other database connections, this is quite unusual. If we (you) decide that this is okay for Calc connections, then this bug here is by design, because then connection pooling implies the behaviour described here. The the most we can do is disabling connection pooling for calc connections by default.
The same spreadsheet document is used to get the list of tables, and to access any of the tables. For performance reasons it is loaded only once. I don't think we should change this.
@Niklas: hmm, I was too unprecise, sorry The problem is as follows: When the user closes all visible references to a spreadsheet data source, and then makes changes to the underlying file, then she would expect that they're visible upon re-opening the "references" (say table views). This expectation is supported by the fact that this is the usual behaviour for any data source type, except Spreadsheet. For spreadsheets, the changes are not visible. The reason is that the SDBC connection is held - for a limited time - in a pool for later re- usage, and in opposite to all other data source types, for Spreadsheet connections the document (and thus all tables!) are refreshed only when a connection is re-opened, not when tables are accessed. We have several options to change this (as far as I can see): a. we declare this a feature, not a bug :). Bad, IMO, because it is against what people expect b. we disable connection pooling by default for spreadsheet data sources. Easy, but somewhat against the idea of resource saving through pooling c. we change the Spreadsheet SDBC driver so that it detects changes in the underlying file, and loads a new copy upon opening a new table. If no other tables are open, then the existent document copy in memory can simply be re-loaded (instead of loading a new copy for the new table access). d. we change the Spreadsheet SDBC driver so that it releases (aka closes) the document when the /last table/ is release (aka closed), _not_ when the connection is freed. You already said that c. is bad for performance reasons. I consider a. definately bad, and b., well, not really satisfying. Thus I suggest d. Niklas, if you say d. is not acceptable, too, then that's your decision. We should close this then as WONTFIX.
*** Issue 10552 has been marked as a duplicate of this issue. ***
comment: issue 8174 talks about another problem with the Calc connection locking the document, which could be solved by doing d., too :)
*** Issue 10736 has been marked as a duplicate of this issue. ***
Please note that issue 10552 is NOT fixed by disabling connection pooling. When I disable connection pooling, the tables in the data source view window are updated, but fields in the document (dragged and dropped from the data source view window before the data source was updated) are not updated.
I'll take a look at it if I find the time, but for now I'll flag the issue for 2.0 as I can't promise anything for 1.1.
Martin, I strongly suspect that in issue 10552, two problems meet: the one here in this bug, and another problem that the Writer does not always properly release it's own connections used for database fields and such. I think that the fields are not updated because the Writer has an old connection, which is not put back in the pool (thus disabling connection pooling does not help). This resource leak in the Writer is fixed in the meantime (AFAIK).
Frank, I also believe that there is more than one bug at work here (which is why I tried to keep issue 10552 alive). I have now tested both 1.0.2 (under Linux) and 643C (under Windows XP), and both still have this bug. Is the fix you refer to more recent than these releases? Note that the problem persists even if I completely exit OOo, then restart - the datasource view updates OK, but the fields in the document do not - so I don't think this bug can be attributed to old connections (I assume connections don't persist when OOo is not running).
> Note that the problem persists even if I completely exit OOo, then > restart - the datasource view updates OK, but the fields in the > document do not - so I don't think this bug can be attributed to old > connections (I assume connections don't persist when OOo is not > running). Martin, I suggest re-opening issue 10552, again :), with the reasoning above. Certainly connections are not persistent across sessions, so it seems you're seeing yet another problem there (it may also be possible that you misunderstand some functionality, I am not sure, because I did not exactly reproduce your problem in 10552 - perhaps some step-by-step description together with sample data are a good idea -, so you may want to ask in e.g. users@sw first :). I've added issues@dba.openoffice.org to 10552, though at the moment it sounds like a writer problem to me, it may be that it's also an DBA issue.
*** Issue 13421 has been marked as a duplicate of this issue. ***
Can reproduce this in OO1.1Beta under 2000
*** Issue 14040 has been marked as a duplicate of this issue. ***
Hi, I thought I would just make a suggestion. What about if the user presses refresh the updated data is obtained. I would be happy with that at this stage. Kelvin
that's finally what the user expects - not sure at the moment how difficult this would be technically, because the "Calc database driver" is somewhat different from others :), but I agree that this is what we should drive for - it's conformant to other databases, and it's (thus) conformant to user expectations.
*** Issue 16798 has been marked as a duplicate of this issue. ***
In my bug 16798 (a dupe of this) I suggest 2 actions: * provide a method for manual refresh (in Data Sources window) * automatically refresh on mail merge By the way, can anyone confirm if it is only Spreadsheet data sources that this bug (connection pooling feature) effects?
> By the way, can anyone confirm if it is only Spreadsheet data sources > that this bug (connection pooling feature) effects? It's not the connection pooling which is the bug here. Connection pooling is only a means to save resources, without it, every time you close and re-open a connection, expensive operations need to be performed to allocate physical resources, again. Switching off connection pooling is only a workaround for the real bug. The problem here is that the Spreadsheet driver does cache too much data, and is this respect behaves much different from other database drivers. So this definately is a spreadsheet-only issue.
*** Issue 11775 has been marked as a duplicate of this issue. ***
*** Issue 19401 has been marked as a duplicate of this issue. ***
*** Issue 19915 has been marked as a duplicate of this issue. ***
*** Issue 20448 has been marked as a duplicate of this issue. ***
I was really hoping this would be fixed in 1.1, but alas. I did find a workaround (but no easier than re-starting OOo): change the name of the data source and exchange database to the (changed) name. This seems to force the driver to re-read the calc file. I had to use this because my install was hosed and I couldn't exit without loosing all my configuration. Maybe helpful for someone else. 1. Disconnect the data source 2. Edit/Admin data, edit the data source name (add a character) 3. Edit/Exchange database, select the 'new' data source
Here is what I believe is a fairly decent work around. <http://www.oooforum.org/forum/viewtopic.php?t=3825>
*** Issue 22462 has been marked as a duplicate of this issue. ***
*** Issue 24299 has been marked as a duplicate of this issue. ***
change subcomponent to 'none'
*** Issue 24215 has been marked as a duplicate of this issue. ***
FS's comments in Jan 2003 describe option A (mark as 'feature') as very bad, then goes on to say that if all options are bad, then mark as 'WONTFIX'. In my world, this is worse than A, since it implies that the bug doesn't even get documented. As for the issue of performance: Perhaps I'm missing something (does it really cause *that* much of a hit?), but there's not much value in getting a RONG answer really, really fast. Things like the workaround of having to save your spreadsheet as a database are not going to occur to the regular user. Even if they do occur, they're going to occur as silly (at best). If connection sharing is the problem, then either (1) turn it off, or (2) create a dialog box when connection sharing is on and spreadsheet data sources are used informing a user that data sharing needs to be off to get sane results. ____ I'm getting a sense that the problem with updating on changes to a spreadsheet come if the spreadsheet has multiple changes in a short period of time (200+ updates in a second) because of calculation dependencies, and each change results in an 'update' event. My solution to this (from a different context) was to start a short timer (say, 1 second) when the first update event arrives. If no no other updates have arrived at the end of that interval, then the update is propogated. If any updates have arrived in that time, then the timer is started again until you have a quiescent period. This results in a maximum delay of 2 seconds between the last update and propogation of the changes (much better than infinity), and a minimum delay of 1 second. At the same time, it avoids the problem of update floods. For sanity's sake, you might set a second timer that forces propogation after more than N periods of non-quiescence.
FS's comments in Jan 2003 describe option A (mark as 'feature') as very bad, then goes on to say that if all options are bad, then mark as 'WONTFIX'. In my world, this is worse than A, since it implies that the bug doesn't even get documented. As for the issue of performance: Perhaps I'm missing something (does it really cause *that* much of a hit?), but there's not much value in getting a RONG answer really, really fast. Things like the workaround of having to save your spreadsheet as a database are not going to occur to the regular user. Even if they do occur, they're going to occur as silly (at best). If connection sharing is the problem, then either (1) turn it off, or (2) create a dialog box when connection sharing is on and spreadsheet data sources are used informing a user that data sharing needs to be off to get sane results.
B (disabling connection pooling) isn't that bad anymore, since in 2.0 we (will) have a) connection sharing and b) a dedicated database application as main entry point. fs->nn: disabling connection pooling is probably the fastest solution, nevertheless I still consider d the "best" one :). Just my cents on this. fs->darkonc: I agree on the seriosity of this issue (too many people have been fooled by this). I suppose others agree, too - that's why the issue is still targeted for "OOo 2.0", and not for "Later" :)
*** Issue 31456 has been marked as a duplicate of this issue. ***
Because of limited resource for OOo2.0, it was decided to shift this tasks to the next milestone. If somebody will be found, who can implement this until OOo2.0, then this tasks will be re-targeted.
Major bummer. Apart from MS Office document compatibility, Mail Merge would have to be the most common aspect of an office product that our users need, and I would have to think they are pretty typical office users! I appreciate that it takes resources and the community to tackle problems, but it is a pity that such a heavily voted issue, with obvious high impact to users converting from MS Office, can't be included in the Q-PCD objectives.
Hello, I have been hit by this "feature" for some hours. The most inefficient way to refresh the database is certainly to have to quit and restart the program or even to reboot the computer, as it happened to me yesterday. If a user presses the button "Refresh database" ("Aktualisieren" in the german version), it should do so, even if takes some time. Is there any way around this bug? I already unchecked the "Verbindungen aufbewahren" switch in the Options/Database dialog, but nothing changes. I cannot imagine that it takes the programmer of this interface more than half an hour to fix the problem. Bugs like this should be taken very seriously by the team: If the transition to Linux/OpenOffice, as it is considered in several larger towns, fails due to such mistakes, there will not be a second chance soon. Alois
*** Issue 39003 has been marked as a duplicate of this issue. ***
> Major bummer. Apart from MS Office document compatibility, Mail Merge would have to be the most common aspect of an office product that our users need, and I would have to think they are pretty typical office users! If this makes a difference to your business, PLEASE see if you can get someone to allocate (or pool with a few people) some money for a bounty on this bug. It'd still be cheaper than paying for MS licenses, and you'd be providing a service to the whole community.
Some additional points: 1) Probably well-known, but when you do a mailmerge in Microsoft Office, the working document always refers to the most recently saved version of the datasource. That does seem the most sensible way. 2) In terms of user workarounds, an easier/quicker way to force the update is to toggle between two datasources. Of course, you have to be "in the know" to do this. 3) As this is an "invisible" bug, and the consequences of a botched mailmerge could be very serious for the user, I strongly recommend that (until fixed) some information message is displayed during mailmerge, advising the user of an approved method of avoiding the issue. Otherwise, the software could fall into disrepute. Cheers, Chris PS: just to lighten the discussion, I have yet to find even one person who can correctly print L7163 labels using Office XP and Windows 2000. The alignment is incorrect. This problem seems to be a new one and there is NO workaround that I have discovered PPS: wrt previous comments, I also find that closing the documents, or even quitting OO altogether, does not force a refresh. Reboot does.
Hi! Maybe it helps: I'm working with StarOffice6. I have exactly the same Problem. Whenever I'm using a spreadsheet as data source for the word processor I don't see updates on the spread at the word proc., even if I close both and reopen the word processor. By accident I've figured out that the word processor process does not kill itself after closing it! I'm using the TaskManager of my XP. Strangely there is no task anymore, but the process is still alive. (I don't use the fast starter) If I'm killing this process by hand and reopen the word processor afterwards I see all changes of the spread in the word proc. So, this helps. But of course it's pretty annoying!
This bug seems to have different behavior according to OS. I followed the sequence: - create sxc file with data for DB, close it - create sxw file, F4, create new DB with previous sxc; insert fields in sxw; save sxw (not close) - re-open sxc file, modify some data, save and close sxc - twice F4 (close and open DB explorer) On SolarisOS with OOo1.1.2(en) data are updated, but not on MS-WinXP-Pro with OOo1.1.4(fr)
Recreating the problem on OOo1.14(en) on XP (Home) 2002 SP2 - Turned off "Connection pooling enabled" in OO's Options - Data Sources - Connections dialogue - Created a test datasource with two labeled fields as a .sxc spreadsheet and input one row of dummy non-blank data. - Created a test textdocument and with Insert - Fields - Other [Database] inserted placeholders. - With View - Data Sources selected the test datasource. (As expected this works and displays the 1st row of data I had made.) - Closed both documents and opened the datasource, added a second row, saved and closed. - Opened the mailmerge test and the new entry made above does not show in the Data Sources viewpane. - Tried both Refresh and Rebuild, disconnect and reconnect, Tools - Update - Update All etc.. All to no avail. Conclusion - ** Disabling connection pooling does not work for me ** What does work is in Administrate Data Sources, remove the data source and make anew with the same name - or Restarting windows.
*** Issue 48250 has been marked as a duplicate of this issue. ***
Regression? Just tested OOo_2.0beta2 (SRC680_m125_native_packed-2_de.8947) on Linux: 1) opened ods-sheet and odb-document which uses ods-sheet as data source 2) changed some fields in ods 3) did not succeed to get them updated in odb-document (by doing a "refresh" or "rebuild") 4) "testing connection" (by right-click on approp. table > properties > test connection [which was helpfull in m104]) did not update the odb-fields note: all this even without connection pooling allowed! 5) Closing base did not help either (when ods was still open) 6) Only by closing *all* instances of OOo the table could be updated correctly
Request: Please lift this bug at least to p2! It has by far the most votes from all database bugs! Who is responsible for this bug? nn - does it mean there is nobody to take it?
*** Issue 54273 has been marked as a duplicate of this issue. ***
Quick and easy work around : 1) Disconnect from the datasource (rightclick on the source or any children, such as for example the "table") 2) re-connect (click on the data source). I would suggest that 1) at least a note be inserted into the documentation/help to warn users that the data "loaded" will remain cached in the calc "driver" for the length of the connection (and provide the workaround) 2) disabling the "refresh icon" so that users will not be lead to believe that their data is up to date <Note> I had not been able to find this original bug through a search on sdbc:calc (and submitted redundant bug 54273). Having read this thread, I'll add that disabling "pooling" is not a workaround (at least not for XP) </Note>
*** Issue 55131 has been marked as a duplicate of this issue. ***
Hello, My experience about this really annoying bug ....( no data refresh mailmerge with ods document as datasource). If you modify/save the spreadsheet datasource and disconnect/reconnect the datasource in the beamer in Writer ... data are refreshed in the beamer and for the mailing. It's an acceptable behaviour (even if refeshing data with the refresh button will be better than connect/disconnect). BUT .... if you use the mailmerge wizard ( and even if you cancel on step 6 ou 7) .... the ONLY way to refresh data after a new spreadsheet data change is to restart OpenOffice ( without forgetting to also stop the quick launch in systray ). (disconnect/reconnect datasource, changing datasource, changing name of datasource ....nothing else ok, the only way is to kill all soffice process) It's seems like mailmerge wizard/process will stuck/lock cached spreadsheet data in memory... tested on Win XP - OOo 2.0.4 fr..
Can I suggest a P2 priority because it's really annoying for final users. We're replacing all our Microsoft Office by OpenOffice ... and many users used Excel + Word to make simple mailmerge operation... It's difficult to replace Excel sheets for adresses data by OpenOffice because of this problem of update in data source when you update the spreadsheet. We can replace Excel sheet by OOoBase ... but it's not so easier for final users. Thanks !
I can confirm what fchauvat states: Simple an intuitive operation is a key issue in migration processes in our place too, and this issue is one of the top blockers.
Hello, OO Writer is great, though I would really be thankful for fixing this bug. What does the user expect? 1. When you use the Mail Merge wizards, there's no hint that OO creates a database file as middle layer between spreadsheet and document. So the average user won't even know that there's a different thing to update. 2. If you did understand at least that, it's not obvious that the name of a) the spreadsheet .ODS (or .xls) b) the database .ODB c) logical data sources name in OO can be similar or different. Example: In step 3 of the Mail Merge wizard, it's called "Adress list". But instead of the spreadsheet file the user has chosen directly ("Add...") here before, the shown "Adress list" is the name of the automatically created "data source" (c). This is neither recognizable by the GUI nor by pressing the "Help"-Button in the "Select Adress list" window. 3. The windows to enter, edit or refresh data a little widespread: - New: "Adress data source" under File -> Wizards - New: Tools -> "Mail Merge Wizard" -> "Adress list" (Why not under File->Wizards, too? Why here a different name than "Data Source"?) - Edit/View: View -> "Data Sources" (F4), here you could disconnect to refresh 4. In the Print Layout View of OO Writer, if you open the serial letters's starting document, the grey data fields for the Mail Merge show the values of the first adress list dataset (e.g. "Bill Gates, Redmond"). This might be quite disturbing when it's not updated, even as user may expect when pressing Tools --> Update. Contrary to that, some word processors don't show the values in the basic document but the name of the data fields ("Firstname, lastname, City"). So they avoid that "Why the h... does it show the old adress??" IMHO, the current solution does work, but unfortunately it is somewhat inconvenient and confusing - my dad wouldn't get refreshing data to work (besides shutting down and restarting OO every time). ;-) Do you think the following ideas might be as well possible and sensible? A) Add a automatic or explicit "refresh" option directly to the Mail Merge Wizard which loads the current spreadsheet data. B) Add the Mail Merge Wizard to the File -> Wizards menu. C) Get that "Refresh" button in the datasource view (F4) to work for ODS. D) Access spreadsheet files directly *without* creating a odb-database. So, enough text written. Bye, thanks a lot! Dirk
I am currently experiencing this problem with 2.1. Create openoffice spreadsheet containing mailmerge data Set up a data source of a given name Mailmerge works OK. Change data in spreadsheet Actual result: Changes not reflected in mailmerge data source or in mailmerge itself. Expected result: Changes in spreadsheet in underlying data source should be reflected in mailmerge. Attempts to resolve: Hit F4 to see data sources. Hit refresh button. Result: No change Hit F4, hit rebuild. Result: No change Close and re-open oowriter mailmerge document. Result: Mailmerge data still does not reflect underlying data source. Close all openoffice applications, re-open mailmerge document. Normally, underlying data will be reflected in mailmerge document after restarting openoffice, but not always. Presumably some other application is holding the libraries open.
I notice the bug was filed more than 4 years ago. I also notice the bug is assigned to "nn (nn)" which is probably not a real person. I also notice the bug is not assigned to any target milestone The bug is flagged as started, which means someone should be working on it. But given it is assigned to a non-existent person, I suspect nobody is working on it. Could someone change the status to Unassigned, or assign it to someone, and set a genuine target milestone? I am happy to offer a bounty of GBP20 (appx 38 USD) good until end of June 2007 to help encourage resolution of this bug.
"Started" is the state after accepting an issue. That can be a bit confusing. I wouldn't call myself non-existent, but I'm not currently working on this. If someone else wants to take a look at it, go ahead.
Oops, I'm sorry nn, I assumed 'nn' was erroneous data in the "Assigned to:" field. I didn't imagine nn being an actual username. I now understand the Status: field is correct, and the bug has been assigned to a real person. No offence was meant, and apologise if any was taken.
i can confirm the bug (OO 2.1.0), please fix it, before working on other features, or be fair and disable this feature until it get fixed. I burned a day checking out whats wrong and finding out that its known since 2002, yes, hey, my dougther was born in 2002 too, you dont really want to know whats she's able to tell ya about live - man. Anybody out there able and willing to fix it???? DO IT!!!! ---- I tested this issue with 3 different machines: # the "refresh symbol" in the F4 Window NEVER works. Windows-XP, JRE 1.5.0_11_b03 -> works fine if you disconnect DataBase and reconnect by "browsing" to sheet1 again. Windows-XP, JRE 1.?? (older one)-> works only AFTER you log-out / log-in (so you force all apps go down, even this one wich locks the database File) Windows-Vista, JRE 1.6.0_b105 -> you just must restart Writer, then the data is refreshed. Good luck, and thanks for your unbelieveable work .... Andreas Filsinger
Hello Andreas I have offered a bounty of £20 to get the bug fixed. If others can join me offering a bounty, maybe the bug would get fixed sooner. I will pay the money to the person who submits a patch accepted by the OO project which solves the bug. Patch to be submitted before end of June, I will pay via Paypal on receipt of an email evidencing the accepted patch. We must remember that even though this bug is annoying and very old, there are still likely bugs in OO which have a higher priority. And, IMO, it is only since V2.04 that the mail merge functionality in OO became sufficiently bug-free to be of general use. Apart from usability issues, this, as far as I am concerned is the last real bug with the OO mail merge, resulting in this bug being conspicuous. I guess this bug can't live for more than 6 months. nn; I know you don't have enough time currently to work on the bug. If the bug were unassigned/ marked as new, is it be more or less likely someone who has time will pick it up? To put it another way, if the bug is marked started, and assigned to you, might that actually stop someone else working on it? I don't have experience of the OO BTS like you do, so this question is asked with naivety and I value your opinion on this matter. Are there any major overhauls of the OO code base planned which may result in the re-coding of the mail merge functions and hence give us a different selection of bugs and perhaps solve this one?
*** Issue 75467 has been marked as a duplicate of this issue. ***
*** Issue 77431 has been marked as a duplicate of this issue. ***
Hello, I would be very happy if this issue could be solved. As I am quit new here (actually because of this defect) I would like to ask if somebody can make suggestions how to overcome this situation. Maybe you nn can tell us what activity or other improvement would be helpful to get this issue a step further in direction of a solution? From my user point of view I would expect as minimum: * update button: The actual data of the last saved calc/excel file to be displayed/used by base * rebuild button: The actual data structure and data of the last saved calc/excel file to be displayed/used by base Thank you! hhoehle
Hello, Is there anybody out there who takes care of this issue or is willing to participate on this discussion? Maybe somebody can give me a hint how we get some movement into this? greetings hhoehle
fs->nn: as talked about and agreed upon: Let's try to do this for 2.4. The general idea is that the connection should be disposed when it is not used anymore, and that the driver should discard the file at this point. Nowadays, it's more reliable that connections are really closed/disposed when they're not needed anymore than at the time when this issue was submitted :-\. If this approach doesn't work, please tell me, and I'll assist in finding a better entry point (or fixing the reasons why it doesn't work).
hhoehle -> fs, nn: Sorry, it took a while to continue this discussion. From my point as user the following behaviour is expected. The set up is that base uses an external db source like a CALC sheet, an excel sheet or an ODBC connection as data source to provide data for a serial letter in writer. After the changed data source file (calc, excel etc.) has been saved, the new data content should be used within base. At least after pushing the “update†button the new data should appear in the data base/table window and should be used for merging the serial letter. This behaviour should be independent of the type of the data base. In case your change proposal would lead to such a result it is more then welcome to be implemented. However no additional action (reconnect ...) should be required to make use of an updated data base content. greetings hhoehle
Hi, re fs's suggestion "the connection should be disposed when it is not used anymore, and that the driver should discard the file at this point.".......could this be implemented such that a new mail merge activity was itself the trigger for disposing of the connection (after which it would, of course, be refreshed)? Then you would be guaranteed the most up to date database every time you did the merge. I guess it might take a second or two longer, but for most people that would be a trivial inconvenience compared to finding after the fact that you used old data.
Not finished in time for 2.4, retargeting.
Hi, As I have a really need for this issue to be solved I feel somewhat disappointed about the schedule shift. Can we expect to see something in 3.0 beta? I may even support you in testing. Please let me know.
Grabbing
I fixed the issue in that way that the document is still loaded only once. But when the last table of the connection dies the document will be closed. When after that new tables will be asked for ( like Menu->View-Refresh Tables) the document will be loaded again. Now every time you create a Mail Merge for an ods (not a datasource, this is a different story) a new connection will be created and the document will be reloaded. When you use a datasource you have to reconnect it to get the new data.
Hello oj, great that you have taken the task! I didn't understand your explanation completely, e.g. "first table, last table", so would you please clarify? 1. For Mail Merge with ODS/XLS-spreadsheets, will there still be an ODB-Database file created? 2. The refreshing from the spreadsheet file is done by calling Tools -> Mail Merge Wizard again? 3. When will we be able to test it? I don't suppose it to be in 2.4. Thank you! :-)
1. Yes. I changed nothing in handling of ods sources inside the wizard. 2. I don't know the work flow but fact is when you close the wizard the ods file will be released (of course when you have any other db instance which has opened the ods file then it won't be released). 3. When the cws dba30a was integrated. It will be part of OOo 3.0.
Please verify. - Create spreadsheet and insert some values - Execute mail merge wizard and select the spreadsheet as data source - Change data in the spreadsheet - Execute the mail merge wizard again => You see the changes.
Thank you very much oj that you took the time to fix this issue! As I am not a 100% sure that I understand right could you please explain the new behaviour in my scenario. Given a calc table as data source of an odb database and a writer document which contains fields references to the odb database (address data like name etc.) Now I change data in the calc file and save it. Then I “print†this writer document and I choose “serial letters†and print some data (OO version 2.3, german) 1. Do you call this printing using the wizard? 2. What would be required to do in minimum to get the letters with the new data out of the calc sheet. 3. With the writer document open f4 shows the actual connected db in bold in the window and provides an update and a reconnect button What would be the function of this buttons? In addition I would like to use the bug fix. Which version should I download and where do I get it? Thank you very much again! hhoehle
Hello hhoehle, to my mind, oj means we have to re-run the Mail Merge Wizard from the "Tools" menu. (German version: Extras -> Serienbriefassistent), which hopefully hasn't forgotten the other settings from the last time. I don't know if other ways work to refresh the writer document with the edited addresses (According to my post from 2007-01-22, see above).
verified in cws dba30a. You need to turn on connection pooling to see a diffrent between OOH m7 and this CWS.
I just started with oo 3.0. The 1st thing I needed was to move a database/label/mail merge from EXCEL/WORD to OO. I created the calc spreadsheet and rebuilt my macros used in EXCEL. I populated the spreadsheet with the EXCEL data. I registered it as a 'datasource'. I defined my label form, did the layout and successfully printed the selected data. However, when I make changes to the spreadsheet, close the spreadsheet and reopened the label document --- changes are not reflected in the datasource. I know this has been a problem since 2002 - but -- do we have a workaround or fix?
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues
I've finnaly updated to 3.3 and... the bug is still present. Come on, people, it's been over 8 years! I have to reopen the text document in order to refresh data. It doesn't get updated when I click "Refresh" ("Odśwież") in "Data sources" ("Źródła danych"), when I "Disconnect" source in the explorer or try to print the mail merge (neither refresh button works). It's good I don't have to restart all OOo windows.