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. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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 | |
|
|