Announcement

Collapse
No announcement yet.

PRINT # problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Phil Myers
    replied
    I was just too inpatient - on the 486 machines and a busy network, it was taking some time to build the file. I was used to running the program on my laptop. What a difference it makes! Thanks for the help.

    ------------------

    Leave a comment:


  • Phil Myers
    replied
    On the machines with the problem, it does not matter whether I write the file to the local drive or to the server. Lance: I will try SLEEP 0 and checking ERR. I plan to do more at client site today. If I cannot get to work, I will post code this weekend. If I do get it work, I'll let you know what I did.

    Thank you everybody for the help.

    ------------------

    Leave a comment:


  • Fred Oxenby
    replied
    I have written/updated billions(!?) of files on Novell networks
    last 10 years (DOS/WINDOWS) and have never seen this problem.
    Ofcourse my customers have been instructed to use Novell Netware Clients,
    and asked never to use Microsoft client.
    That said, there were a problem with early Netware Client32.
    Caching did not work correctly.
    When you say you have problems with "slower machines" this could
    mean that you have older pc perhaps using old Netware Client32.



    ------------------
    Fred
    mailto:[email protected][email protected]</A>
    http://www.oxenby.se

    Leave a comment:


  • Semen Matusovski
    replied
    Phil --
    Novell Netware has own life and uses own buffers.
    At least it was so in 3.11, when I wrote first (DOS) network apps.
    In my DOS program, written about 6 years ago, I didn't found another way like LOCK - CHANGE - CLOSE - OPEN - UNLOCK.
    Not fast, but works.
    Try to close file after each update.

    [This message has been edited by Semen Matusovski (edited March 10, 2000).]

    Leave a comment:


  • Lance Edmonds
    replied
    It sounds unusual to say the least, Phil.

    What version of Windows are you using? Is the problem only occurring on a mapped drive or on the local drive too? Do you keep the file open continiuously or are you just opening it to write? Are you checking ERR for runtime errors after each file I/O statement?

    In case it is (some sort of) a redirector problem, try adding a SLEEP 0 after the PRINT# / FLUSH# statements to cede the current timeslice to the O/S.

    Finally, can post the code that you are using in case we can spot anything subtle?


    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Phil Myers
    started a topic PRINT # problems

    PRINT # problems

    I have an application writted in PBDLL 6.0 that opens a file FOR OUTPUT and writes to it using PRINT. This appliction runs on a NOVELL network. On some computers the file gets written out fine, on others, a few bytes get written (maybe 2000 bytes or so) and then the program hangs. It seems to be that the faster the PC and the more memory, the less the chance it will hang. One thing I thought of after I left client site was that maybe I should use FLUSH after PRINT; currently using no FLUSH statements. The longest PRINT string would be maybe 150 bytes. One thing I did while on site was to put MSGBOX stmt after each PRINT so that I had to click "OK" after each PRINT stmt, and it worked fine on the machines it had hung on. That made me think that maybe that was slowing things down and machine had opportunity to flush buffers. Of course I wasn't smart enough to think of that while still on site!

    Any help much appreciated.
Working...
X