acOutputTable - cannot save output data

[tomblower]

Access 2000 fully updated
Three PCs manage data held on a server. They each have a front-end mdb
file linked to tables on the server and on each PC.

A problem has arisen over the following line of code.

DoCmd.OutputTo acOutputTable, "tblMarriageLic ence", acFormatRTF, strRTFFolder & "\Marlicm.r tf", False

The linked table has just been updated and is held in another MDB file
on the local PC. The target folder is on the local PC. As you can see,
the file name is always the same, so the existing file is being
overwritten. This line of code has worked in numerous locations and in
this particular one without ever failing until all three PCs in this
location start getting error messages last Friday!

Error 2303 - Cannot save output data to the file you selected.
Error 2308 - File already exists, Marlicm.rtf

One assumes a locking problem. There should be no question of rights or
permissions as all the files affected are on each local PC. After the
error, it is impossible to delete the RTF file "in use by another
user". Close Access and it can be deleted.

The procedure now works - ONE TIME - the file was not there to be
overwritten.

I am not aware of any change having been made. The front-end
application mdbs were updated on the Tuesday and everything worked fine
as usual until the Friday.

What is very strange, is that another routine in the same form module,
using exactly the same line of code, but with another file name -
same location of files overwriting the RTF file - still works. That
RTF file was copied and renamed as the problem file, but the same error
occurred.

Another form module has the same problem.

Can anyone point to a solution - other than deleting the RFT file
before running the code - which is really ham-fisted?

Thanks

[Anthony England]

<to*******@tisc ali.co.uk> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...

Access 2000 fully updated
Three PCs manage data held on a server. They each have a front-end mdb
file linked to tables on the server and on each PC.

A problem has arisen over the following line of code.

DoCmd.OutputTo acOutputTable, "tblMarriageLic ence", acFormatRTF,
strRTFFolder & "\Marlicm.r tf", False

The linked table has just been updated and is held in another MDB file
on the local PC. The target folder is on the local PC. As you can see,
the file name is always the same, so the existing file is being
overwritten. This line of code has worked in numerous locations and in
this particular one without ever failing until all three PCs in this
location start getting error messages last Friday!

Error 2303 - Cannot save output data to the file you selected.
Error 2308 - File already exists, Marlicm.rtf

One assumes a locking problem. There should be no question of rights or
permissions as all the files affected are on each local PC. After the
error, it is impossible to delete the RTF file "in use by another
user". Close Access and it can be deleted.

The procedure now works - ONE TIME - the file was not there to be
overwritten.

I am not aware of any change having been made. The front-end
application mdbs were updated on the Tuesday and everything worked fine
as usual until the Friday.

What is very strange, is that another routine in the same form module,
using exactly the same line of code, but with another file name -
same location of files overwriting the RTF file - still works. That
RTF file was copied and renamed as the problem file, but the same error
occurred.

Another form module has the same problem.

Can anyone point to a solution - other than deleting the RFT file
before running the code - which is really ham-fisted?

Thanks

I don't see why deleting the file first would be such a bad idea - if this
produced an error it might help you diagnose the problem. Having said that,
if the problems suddenly started to occur one particular Friday, then I
would investigate possible corruption in the table which might be causing
this. Does this table have 1 or more memo fields? Try a compact and repair
of the back end first or try changing the code to output another table
(ideally a small lookup table with no memo fields) but use the same file
location - does this produce the same error?

[tomblower]

Thanks Anthony.
I will try what you suggest. I was concerned that deleting the file
first was impracticable, since it was locked whilst Access was running
and the user would have to unload Access each time before the delete,
which would mean continuous loading and unloading. Anyway - why go to
that solution when the thing has been working perfectly satisfactorily
for years. That fact alone would point to your line of thinking.

[tomblower]

There are no memo fields. Other RTF files are output successfully to
the same location. I have the table here and there is nothing wrong
with it.
Compact & repair did not solve the issue. Access succeeds in creating a
RTF file, but the file remains locked until Access is closed. I now
have the RTF file created by the user here and I am unable to link it
to a merge document, nor open it in Word. The Word message says
"Document name or path is not valid - check file permissions". I am
working as adminstrator on this PC, so I cannot think there are
problems with permissions.
What is happening is that even if the file is deleted first with Access
closed and then the Access procedure is run, the file is created but
locked so that Access then says it cannot proceed to output the data. I
cannot see what is in the file, so I do not know whether it contains
any data.
The procedure works OK for me here.
As the problem arises with one particular Access form I can only think
there is a problem there. What is odd is that more than one user has
the problem and they all have exactly the same mdb file on their PCs as
the front-end application.
So I am stuck again.
Any ideas?

[Anthony England]

<to*******@tisc ali.co.uk> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

There are no memo fields. Other RTF files are output successfully to
the same location. I have the table here and there is nothing wrong
with it.
Compact & repair did not solve the issue. Access succeeds in creating a
RTF file, but the file remains locked until Access is closed. I now
have the RTF file created by the user here and I am unable to link it
to a merge document, nor open it in Word. The Word message says
"Document name or path is not valid - check file permissions". I am
working as adminstrator on this PC, so I cannot think there are
problems with permissions.
What is happening is that even if the file is deleted first with Access
closed and then the Access procedure is run, the file is created but
locked so that Access then says it cannot proceed to output the data. I
cannot see what is in the file, so I do not know whether it contains
any data.
The procedure works OK for me here.
As the problem arises with one particular Access form I can only think
there is a problem there. What is odd is that more than one user has
the problem and they all have exactly the same mdb file on their PCs as
the front-end application.
So I am stuck again.
Any ideas?

The code works flawlessly on my machine. I did a quick Google on
"DoCmd.Outp utTo fails" and see various things mentioned like registry
settings ... but when it occurs on multiple machines it seems unlikely.
Perhaps you could have a search and see if anything sounds possible. If
other tables can be output, but not this one, then I wonder what is special
about this one. Perhaps it is specially big?
Perhaps someone else is following this thread but I am out of ideas. Of
course you could write your own routine to output the file and bypass the
docmd method entirely but it might be tricky to do the rtf format and may
end up being slower than the built-in method.

[Lyle Fairfield]

Perhaps, the files ReadOnly attribute has been set.

You might try the following to see if it helps.

On Error Resume Next
SetAttr strRTFFolder & "\Marlicm.r tf", GetAttr(strRTFF older &
"\Marlicm.r tf") And Not vbReadOnly
On Error GoTo 0
DoCmd.OutputTo acOutputTable, "tblMarriageLic ence", acFormatRTF,
strRTFFolder & "\Marlicm.r tf", False

or
SetAttr strRTFFolder & "\Marlicm.r tf", vbNormal

[tomblower]

Thanks for the input. I spent the best part of a day on site trying to
get to the bottom of the problem.

The problems all arise from the one table. Records in this table are
deleted and then a fresh record is added, with data from the main
database held on the server. That record is then output to RTF file.
The table being putput and the RTF file are both on the local PC. What
is happening is that the export does not finish, leaving the file
effectively open, so that when it comes to the Word merge using that
RTF file, Word cannot open it etc etc. Moreover the data in the file is
not always correct with some fields showing #error. I tried exporting
the table using the export function in the right-click menu and got the
same result. The problem is intermittent, which adds to the gloom!

I then re-created the table from scratch. After a few successes the
same problem arose.

I discovered that one PC has a later version of Access2000, (9.0.6926
SP-3), and the problem does not occur on that PC. The other two have
9.0.3821 SR-1. I will get them updated as that may well be the cause of
the trouble. What really foxes me is that this routine has been used
for about 5 years on various sites and never before has this problem
occurred.

Could it be worth re-creating the bound form where the data input is
made, or the query underlying the form? The table with the data files
has 37 fields and the file being exported has 54 fields.

[Anthony England]

<to*******@tisc ali.co.uk> wrote in message
news:11******** *************@o 13g2000cwo.goog legroups.com...

Thanks for the input. I spent the best part of a day on site trying to
get to the bottom of the problem.

The problems all arise from the one table. Records in this table are
deleted and then a fresh record is added, with data from the main
database held on the server. That record is then output to RTF file.
The table being putput and the RTF file are both on the local PC. What
is happening is that the export does not finish, leaving the file
effectively open, so that when it comes to the Word merge using that
RTF file, Word cannot open it etc etc. Moreover the data in the file is
not always correct with some fields showing #error. I tried exporting
the table using the export function in the right-click menu and got the
same result. The problem is intermittent, which adds to the gloom!

I then re-created the table from scratch. After a few successes the
same problem arose.

I discovered that one PC has a later version of Access2000, (9.0.6926
SP-3), and the problem does not occur on that PC. The other two have
9.0.3821 SR-1. I will get them updated as that may well be the cause of
the trouble. What really foxes me is that this routine has been used
for about 5 years on various sites and never before has this problem
occurred.

Could it be worth re-creating the bound form where the data input is
made, or the query underlying the form? The table with the data files
has 37 fields and the file being exported has 54 fields.

Just a quick thought:
If it has suddenly started happening, then what could have changed? We
previously discussed corruption and that was ruled out - but you can get
problems when the data changes (without it being corrupt). I recently got
called in to troubleshoot a problem where reports had weirdly stopped
printing and it turned out that it was trying to keep the data on one page
but since the database had been set up, the data now had quite long memo
fields which couldn't be printed on one page. Access got stuck in a
perpetual loop each time moving to a page to see if it had enough room to
print the section - which it never did.
The point I am making is that it might be possible that the data has 'funny
characters' in it which is stopping the DoCmd.OutputTo from working
properly. Could you imagine taking a copy of the data, deleting all the
records, then adding some very standard entries and re-trying the code? In
this way, you might be able to narrow down the cause of this problem.

[Lyle Fairfield]

Anthony England wrote:

The point I am making is that it might be possible that the data has 'funny
characters' in it which is stopping the DoCmd.OutputTo from working
properly.

You think he has some unfortunate person named George Bush in his db?

---------

Today, China ... Tomorrow, the World!

[Anthony England]

"Lyle Fairfield" <ly***********@ aim.com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

Anthony England wrote:

The point I am making is that it might be possible that the data has
'funny
characters' in it which is stopping the DoCmd.OutputTo from working
properly.

You think he has some unfortunate person named George Bush in his db?

---------

Today, China ... Tomorrow, the World!

Dan Quale counts as a 'funny character' (apparantly Mikey Mouse wears a Dan
Quale watch) - however I'm not sure Bush qualifies.