A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Setting Up & Running Reports
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Code to delete and import reports



 
 
Thread Tools Display Modes
  #11  
Old January 7th, 2009, 06:54 PM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
Clifford Bass[_2_]
external usenet poster
 
Posts: 1,295
Default Code to delete and import reports

Hi David,

Noted.

Clifford Bass

"David W. Fenton" wrote:

[snip]

I don't give a rat's ass what you think about my tone.

  #12  
Old January 7th, 2009, 07:28 PM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
Larry Linson
external usenet poster
 
Posts: 3,112
Default Code to delete and import reports

wrote

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


  #13  
Old January 7th, 2009, 11:35 PM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Code to delete and import reports

"Larry Linson" wrote in
:

wrote

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.


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

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
  #14  
Old January 8th, 2009, 12:25 AM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
Clifford Bass[_2_]
external usenet poster
 
Posts: 1,295
Default Code to delete and import reports

Hi Douglas,

You input with a possibility is appreciated!

Clifford Bass

"Douglas J. Steele" wrote:

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!)

  #15  
Old January 8th, 2009, 11:29 PM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Code to delete and import reports

"Douglas J. Steele" wrote in
:

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.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
  #16  
Old January 31st, 2009, 04:12 AM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
Jack Cannon
external usenet poster
 
Posts: 151
Default Code to delete and import reports

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

"Douglas J. Steele" wrote:

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/




  #17  
Old January 31st, 2009, 06:32 AM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Code to delete and import reports

On Fri, 30 Jan 2009 20:12:00 -0800, Jack Cannon
wrote:

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?
--

John W. Vinson [MVP]
  #18  
Old January 31st, 2009, 08:20 AM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
Jack Cannon
external usenet poster
 
Posts: 151
Default Code to delete and import reports

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


"John W. Vinson" wrote:

On Fri, 30 Jan 2009 20:12:00 -0800, Jack Cannon
wrote:

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?
--

John W. Vinson [MVP]

  #19  
Old January 31st, 2009, 10:55 PM posted to microsoft.public.access.reports,microsoft.public.access.modulescoding
David W. Fenton
external usenet poster
 
Posts: 3,373
Default Code to delete and import reports

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

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.

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




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 03:47 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.