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. ***

*** Issue 10552 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.