>This seems a very complex method of printing a report. Why not use cursors
>for your report tables and call the REPORT FORM from within the main exe? I
>appreciate that you have probably simplified the scenario for the [post and
>that there are probably other, very good, reasons why you are doing it this
>way. If you are using the printing exe in several apps then perhaps you
>should be making it a class?
>
>{I know, it's great when you ask for help and someone says - 'I wouldn't
>have done it that way in the first place' <g> }
Yes, that's always fun. But I'm used to it because my programming style has
always been idiosyncratic. For example, my framework uses my own buffering
and update-conflict resolution systems, and eschews data-binding, because
the weird ambiguities, unreliabilities, and lack of control opportunities
in VFP's versions of those things frustrated me to no end. I'm sure some of
it is just my intellectual inability to grasp how those systems work
(though I know in some situations they absolutely don't work as
advertised)--but I do understand how MY system works and thus I can ensure
it works correctly.
So, there are three reasons for my separate printing program, based on
experience with previous VFP apps I've developed:
1. I've observed that printing from a VFP app can use a lot of machine
resources, especially on the older computers that I have to support.
Everything slows waaaay down. I thought that a separate .exe for printing,
running in its own thread, would force a fairer allocation of resources so
that things wouldn't bog down so much. This appears to be true.
2. One of my printing tasks can throw dozens or even a couple hundred
separate printing jobs at the Windows printing spool very rapidly. On some
computer/printer combinations, this can cause a freeze-up. My current app
lets the user set the maximum number of these jobs that can be generated in
one run, but until the user figures out the optimum number, if there's
going to be a freeze I'd rather it be in my printing .exe than in my main
app, where a forced shutdown via three-finger salute could corrupt data.
3. In previous applications I've seen users cause index, memo or header
corruption by attempting to alter data as that data was being printed. (In
Word, for example, you can start printing a document, realize it contains a
mistake, and correct it as the print job is running. The change won't
appear in the printed output but it won't cause a problem either.) In my
VFP apps when a user does this, sometimes the data gets scrambled,
requiring a DELETE TAG ALL and index recreation, or sometimes the good old
copy-the-table-contents-to-a-new-table dodge to clear memo or header
corruption.
I don't expect this to happen, since I never do simple reports directly
from actual tables; I always created separate temporary cursors for
reports. But it happens (perhaps in part because VFP "lies" sometimes about
when it's creating a cursor--sometimes it just filters a real table, and
there are some aspects of VFP's filtering that may surprise you; for
example, if you issue GO [recordnumber] on a table whose filter excludes
that record, the record pointer will STILL go there, with, perhaps,
unseemly results. I don't use filters; I prefer SQL SELECT queries instead,
but this leads me to believe that VFP may violate its own "rules" under the
hood in other ways that we just don't understand.)
I thought that having a separate printing .exe with temporary tables would
absolutely guarantee a complete and total disconnect from the application's
permanent data. This was the most important reason for this strategy, and
it has worked. This application has been running with over 60 users on a
LAN for four months and there hasn't been a single instance of corruption.
So, any thoughts about my original problem with synchronization?
Ken Dibble
www.stic-cil.org
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 9:36 PM
_______________________________________________
Post Messages to: [EMAIL PROTECTED]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
