Can I save a report created on a replica?

I am new on replication. Is there anyway I can save a report created on
a replica? it is only for using on that replica. Thanks for any
suggestion.

m:When you say "save a report" what do you mean? Save as what? Aspreadsheet?

m:


When you say "save a report" what do you mean? Save as what? A
spreadsheet? An RTF file? A PDF? A text file?

Replication does not alter any of this functionality at all.

Indeed, the implication of your question is that your report is
replicated, and if that is the case, then somebody somewhere along
the line has made a mistake. Jet Replication works reliably and
smoothly only for pure Jet objects (tables and replicas), and, thus,
only back end data files should be replication. Of course, any
properly-designed application will be split, with data tables in one
MDB and everything else in the front end MDB that uses linked tables
to access the data in the data MDB.

It would not suprise me if your app is not split and this is why
replication was chosen, so that somebody could make changes to the
application without losing the data.

The app needs to be split (as does every Access app), and only the
back end should be replicated (if it should be replicated at all).

--
David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

I am sorry. I did not explain the situation clearly.

I am sorry. I did not explain the situation clearly.
We have this main database on the server and several replicas on every
worker's computers. Most contents in the database are replicable. Some
workers want to make their own report on their replicas. Other people
do not need these reports therefore these report do not need to be
replicable. Right now, they can create it but can not save it. So I am
wondering is there a way to save it instead of use design master

Replication is for data, not for forms/reports/etc.

Replication is for data, not for forms/reports/etc. There is clearly
a design error in your application, since you appear not to have
split your app (with data tables in one MDB and forms/reports/etc.
in another with links to the tables in the back end MDB), or you
have split but you are replicating front-end objects.

Replication is a Jet technology and works reliably only with pure
Jet objects. When applied to Access objects like forms/reports/etc.,
it eventually leads to problems.

Second, there is never any justification for replicating a front
end, as updating it is as easy as providing a new copy. The only
reason to replicate a front end is when you have made the mistake of
not splitting.

Once split and unreplicated, users can create all the reports they
want. However, when a new version of the front end is sent out, they
will lose their reports if they do not save the old file. Because of
this issue, most developers who have to accomodate users who are
creating their own objects will provide a separate MDB for them to
create their custom objects. it is also helpful to periodically check
what reports users are creating and incorporating the broadly useful
ones into the main application front end.

But the first thing that has to happen is getting rid of replicating
front-end objects. You'll never solve your current problem with a
replicated front end, it is dangerous in the long run (corruption
eventually creeps into the objects and you can lose the entire VBA
project), and it serves no useful purpose at all (replication as a
one-way operation is not of much use -- it is only two-way exchanges
that you need a reliable subsystem for synchronizing, and front ends
do not have anything in them that needs to be sent back).

--
David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Apparently, I need to study more on this issue.

Apparently, I need to study more on this issue. Thank you very much
for your reply, David. I really apreciate for your such detail
information.

John

You might find the Jet Replication Wiki helpful:http://dfenton.

You might find the Jet Replication Wiki helpful:

http://dfenton.com/DFA/Replication/

...particularly the "what not to believe" section and the "best
practices."

On the issue of splitting, Tony Toews has the best information, I'd
say:

http://www.granite.ab.ca/access/splitapp/

One easy and very robust way to distribute your front-end updates is
Tony's utility created for that purpose, available here:

http://www.autofeupdater.com/

He's too modest in his splitting articles to promote his own work,
it seems.

--
David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/