Code to delete and import reports

I would like to delete an existing report in my application and import a
different report as a replacement.
This can be done on the menu bar by going to File/Get External Data/Import.
However I need to accomplish these functions using VBA code instead of
manually clicking on the menu items.
Is there a means to use VBA code to delete existing reports in my
application and import replacement reports from an external database?

Thanks Much,
Jack Cannon

To delete a report, use

DoCmd.DeleteObject acReport, "NameOfReport"

To import a report from another database, use

DoCmd.TransferDatabase acImport, "Microsoft Access", _
"C:\Folder\File.mdb", acReport, "NameOfReportInSource", _
"NameOfReportInDestination"

That assumes that you're trying to import a report named
NameOfReportInSource from the database C:\Folder\File.mdb into your active
database and you want to name the report "NameOfReportInDestination"

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Jack Cannon" wrote in message
...
I would like to delete an existing report in my application and import a
different report as a replacement.
This can be done on the menu bar by going to File/Get External
Data/Import.
However I need to accomplish these functions using VBA code instead of
manually clicking on the menu items.
Is there a means to use VBA code to delete existing reports in my
application and import replacement reports from an external database?

Thanks Much,
Jack Cannon

On Mon, 5 Jan 2009 10:11:02 -0800, Jack Cannon
wrote:

Is there a means to use VBA code to delete existing reports in my
application and import replacement reports from an external database?

Sure. Take a look at the VBA help for the Delete method and the
TransferDatabase method.
--

John W. Vinson [MVP]

Thank you both Doug and John.
This was precisely what I was looking for
and I greatly appreciate the prompt and
very clear responses.

Jack Cannon

"Jack Cannon" wrote:

I would like to delete an existing report in my application and import a
different report as a replacement.
This can be done on the menu bar by going to File/Get External Data/Import.
However I need to accomplish these functions using VBA code instead of
manually clicking on the menu items.
Is there a means to use VBA code to delete existing reports in my
application and import replacement reports from an external database?

Thanks Much,
Jack Cannon

Jack Cannon wrote:

I would like to delete an existing report in my application and import a
different report as a replacement.
This can be done on the menu bar by going to File/Get External Data/Import.
However I need to accomplish these functions using VBA code instead of
manually clicking on the menu items.
Is there a means to use VBA code to delete existing reports in my
application and import replacement reports from an external database?

Why would you not just replace the complete FE MDB/ACCDB/MDE/ACCDE
file? Reports can sometimes require forms or VBA code to exist so it
isn't always as simple as you'd like it to be.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

=?Utf-8?B?SmFjayBDYW5ub24=?=
wrote in :

Thank you both Doug and John.
This was precisely what I was looking for
and I greatly appreciate the prompt and
very clear responses.

Let me weigh in by saying that I think it's a stupid idea to be
programming this into your app. There is no conceivable
justification for a production application to need to do this
programmatically.

Well, I guess if you've already screwed up by not splitting the app
you might need to do this to roll out updates to your app. But
that's one error forcing you to make another error -- if you fixed
the first error, i.e., by splitting, chances are the need to delete
and import reports would vanish.

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

splitting doesn't help.

Moving to SQL Server _DOES_





On Jan 6, 12:08*pm, "David W. Fenton"
wrote:
=?Utf-8?B?SmFjayBDYW5ub24=?=
wrote :

Thank you both Doug and John.
This was precisely what I was looking for
and I greatly appreciate the prompt and
very clear responses.

Let me weigh in by saying that I think it's a stupid idea to be
programming this into your app. There is no conceivable
justification for a production application to need to do this
programmatically.

Well, I guess if you've already screwed up by not splitting the app
you might need to do this to roll out updates to your app. But
that's one error forcing you to make another error -- if you fixed
the first error, i.e., by splitting, chances are the need to delete
and import reports would vanish.

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

Hi David,

I think you need to be careful about calling his need stupid and you
need to be careful about saying there is no conceivable need. While I cannot
come up with any reason at the moment, there could be some reasons, even with
a split database. Do you know for a fact that he is not using a split
database? If not, then again, be careful about saying he messed up by not
splitting it up. A better tack to take would be to ask him why he needs to
do it, then without demeaning words, if there is a better way to do it, point
him in that direction.

Sincerely,

Clifford Bass

"David W. Fenton" wrote:

=?Utf-8?B?SmFjayBDYW5ub24=?=
wrote in :

[snip]

Let me weigh in by saying that I think it's a stupid idea to be
programming this into your app. There is no conceivable
justification for a production application to need to do this
programmatically.

Well, I guess if you've already screwed up by not splitting the app
you might need to do this to roll out updates to your app. But
that's one error forcing you to make another error -- if you fixed
the first error, i.e., by splitting, chances are the need to delete
and import reports would vanish.

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

One possibility would be allowing each user to create his/her own reports as
part of the application. You might then want to import some of the custom
reports back into the main application so that each user can take advantage
of specific reports.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)


"Clifford Bass" wrote in message
...
Hi David,

I think you need to be careful about calling his need stupid and you
need to be careful about saying there is no conceivable need. While I
cannot
come up with any reason at the moment, there could be some reasons, even
with
a split database. Do you know for a fact that he is not using a split
database? If not, then again, be careful about saying he messed up by not
splitting it up. A better tack to take would be to ask him why he needs
to
do it, then without demeaning words, if there is a better way to do it,
point
him in that direction.

Sincerely,

Clifford Bass

"David W. Fenton" wrote:

=?Utf-8?B?SmFjayBDYW5ub24=?=
wrote in :

[snip]

Let me weigh in by saying that I think it's a stupid idea to be
programming this into your app. There is no conceivable
justification for a production application to need to do this
programmatically.

Well, I guess if you've already screwed up by not splitting the app
you might need to do this to roll out updates to your app. But
that's one error forcing you to make another error -- if you fixed
the first error, i.e., by splitting, chances are the need to delete
and import reports would vanish.

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

=?Utf-8?B?Q2xpZmZvcmQgQmFzcw==?=
wrote in
:

I think you need to be careful about calling his need stupid
and you
need to be careful about saying there is no conceivable need.

I'll call stupid what I consider to be stupid. You don't have to
like it, though.

While I cannot
come up with any reason at the moment, there could be some
reasons, even with a split database. Do you know for a fact that
he is not using a split database?

If he *is* split, then there's absolutely not possible reason to
need to do it.

If not, then again, be careful about saying he messed up by not
splitting it up. A better tack to take would be to ask him why he
needs to do it, then without demeaning words, if there is a better
way to do it, point him in that direction.

It's a dumb, dumb idea. There is no reason for it, except as a way
to get around an application design error, e.g., a non-split app.

This is my opinion, of course, and I'm entitle to express.

You, likewise, are entitled to express your opinion that I'm being
rude, impolitic, whatever, and I'm entitled to tell you I don't give
a rat's ass what you think about my tone.

HTH.

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