Ken Dibble wrote:
>> 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.)
VFP uses filters as a way to speed up a query. If you don't want filters
to be used you should state it in the SELECT explicitly, see the option
NOFILTER in SELECT's help.
>
> 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
>
>
>
>
_______________________________________________
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.
