Code to delete and import reports

[Jack Cannon]

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

 

[Douglas J. Steele]

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"

 

[John W. Vinson]

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.

 

[Jack Cannon]

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

 

[Tony Toews [MVP]]

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/

 

[David W. Fenton]

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.

 

[aaron.kempf]

splitting doesn't help.

Moving to SQL Server _DOES_

 

[Clifford Bass]

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

 

[Douglas J. Steele]

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

(no e-mails, please!)

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

=?Utf-8?B?SmFjayBDYW5ub24=?= <[email protected]>
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]

=?Utf-8?B?Q2xpZmZvcmQgQmFzcw==?=

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.

 

[Clifford Bass]

Hi David,

Noted.

Clifford Bass

:

[snip]

 

[Larry Linson]

splitting doesn't help.

Splitting is part-and-parcel of the solution you recommend over and over,
whether or not it applies -- Access ADP with SQL Server data storage. The
ADP does not contain the data; the SQL Server backend does.

Moving to SQL Server _DOES_

Moving to SQL Server IMPLIES splitting the UI Application (Client) from the
data.

Larry Linson
Microsoft Office Access MVP

 

[David W. Fenton]

Splitting is part-and-parcel of the solution you recommend over
and over, whether or not it applies -- Access ADP with SQL Server
data storage. The ADP does not contain the data; the SQL Server
backend does.


Moving to SQL Server IMPLIES splitting the UI Application (Client)
from the data.

Sometimes Aaron is not lying -- he's just too stupid to understand.

 

[Clifford Bass]

Hi Douglas,

You input with a possibility is appreciated!

Clifford Bass

 

[David W. Fenton]

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.

I don't see this as part of a production app, but as a development
task. And I don't see why it would need to be automated in code.

 

[Jack Cannon]

Doug,

This is precisely the objective. Yes I could issue different versions for
each
user and I have been doing that. However the overhead is huge each time
I release an update for the application.

To be more specific the application is for probation services companies. The
problem that is inherent in the application is that every judge in every court
has their own idea of how a warrant should be designed. And, of course, it is
not possible to explain the problems to a judge.

Deleting and importing reports is one possible solution to the problem.
Another possibility is to implement the reports in a Word Document and
use the MailMerge operation to insert the appropriate data in their respective
fields. The individual Word Documents can then be designed to
accommodate each judge's opinion.

Jack Cannon

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

(no e-mails, please!)

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

=?Utf-8?B?SmFjayBDYW5ub24=?= <[email protected]>
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.

 

[John W. Vinson]

To be more specific the application is for probation services companies. The
problem that is inherent in the application is that every judge in every court
has their own idea of how a warrant should be designed. And, of course, it is
not possible to explain the problems to a judge.

Deleting and importing reports is one possible solution to the problem.
Another possibility is to implement the reports in a Word Document and
use the MailMerge operation to insert the appropriate data in their respective
fields. The individual Word Documents can then be designed to
accommodate each judge's opinion.

Wouldn't the judges be concerned with the *CONTENT* of the warrent (which
could be stored in a memo field)? Are they really concerned with the margins
and font and spacing?

 

[Jack Cannon]

John,

While parts of the warrant are indeed stored in a Memo field, there remains
many considerations other than margins, font and spacing. Actually I haven't
received any criticisms regarding margins, font and spacing.

There is both a front and a back to the warrant. Some judges are fussy
about what appears on the front versus what appears on the back. There are
multiple columns and one side may be portrait and the other side landscape.
They can also be critical not only of paragraph content but of paragraph
placement too. Some want pictures on the warrant. Others do not. They
frequently disagree on the legal interpretations. Some will legislate from
the bench. Some judges want the height in inches but others claim that their
officers need the height in feet and inches because "their officers cannot
convert inches to feet". (Yes, that claim has really been made.)

Actually the most consistent portion is the actual fields; name, address,
charge, case #, specific violation of probation, etc. It is fairly easy to
get the fields in the proper place using field placement, bookmarks, merge
location, etc. The
difficult part is trying to keep all judges demands within a single
application. If updates did not occur then it would not be much of a
problem. However, I have been responding to requests for additional
functions within the application for the past four years. It is not unusual
to distribute updates multiple times a week.

At this time I am pursuing the use of the mailmerge function in Word to
accomplish the objective (as opposed to importing reports) where each judge,
court, etc. would receive their custom designed documents and the field list
is the same for all recipients.

The problem is not limited to the judges. Circuit court clerks cannot agree
on their requirements. This leads to different designs for the court reports
- even with the same information. The probation services companies have
their own list of requirements, which often results in variations in the
design of their internal reports. The accountants hired to oversee or audit
the handling of the funds collected by the probation company also have their
unique set of requirements which can result in variations in report design.

I spent over twenty years working in a think tank or advanced technology
laboratory in IBM. I recall complaining about complex governmental
regulations making our job difficult. The response was that I should
thrilled about such complexity otherwise there would not be an IBM. I see
the probation services application in a similar light. If it wasn't for the
complexity of the demands I wouldn't have the job.

Jack Cannon

 

[David W. Fenton]

Deleting and importing reports is one possible solution to the
problem. Another possibility is to implement the reports in a Word
Document and use the MailMerge operation to insert the appropriate
data in their respective fields. The individual Word Documents
can then be designed to accommodate each judge's opinion.

This is the way I've always implemented "user-editable" reports.