Skip to main content

[archive] Data Through put when working on Network.

  • June 19, 2009
  • 11 replies
  • 0 views
D

[Migrated content. Thread originally posted on 18 June 2009]

We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.

    11 replies

    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    We have had issues with some of the firewall and virus checkers using mapped drives. Make sure any of this software is not checking all network traffic for your application.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    We have had issues with some of the firewall and virus checkers using mapped drives. Make sure any of this software is not checking all network traffic for your application.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    We have had issues with some of the firewall and virus checkers using mapped drives. Make sure any of this software is not checking all network traffic for your application.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    If you have a reproducible case, I suggest you contact Tech support for an issue like this.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.


    One of the things I've been testing in when reporting on large files is to get the environment var "TEMP" and copy the files to that directory, then set the "FILE-PREFIX" environment var to what is in "TEMP", then run the report files from the local temp directory. Reports that normally take 5 minutes to run across the network take less than a minute to copy and run.

    It's amazing to see that when copying files across the network, I see 50 to 60 % throughput on the Task manager network connections, yet when reading files across the network, it is always less than 10% throughput. We are using a 100mb network.


    First I get the current working dir to see if I'm working across the net or not.

    MOVE SPACES TO CurrentWorkingDirectory
    CALL "C$CHDIR" USING CurrentWorkingDirectory

    If the first character of "CurrentWorkingDirectry" not = to "C" or "D" then I assume that we are connected to a network.

    IF not (CurrentWorkingDirectory(1:1) = "C" or "D")
    perform Set-For-Net.
    perform Open-Item-Data.
    Perform Process-Report.

    Set-For-Net.
    accept temp-dir from environment "TEMP".
    set environment "FILE-PREFIX" to temp-dir.
    INSPECT TEMP-DIR REPLACING TRAILING SPACE BY NULL
    STRING
    TEMP-DIR DELIMITED BY NULL,
    "\\ITEMDATA" DELIMITED BY SIZE
    INTO TEMP-DIR
    INSPECT TEMP-DIR REPLACING TRAILING NULL BY SPACE
    CALL "C$COPY" USING "ITEMDATA", TEMP-DIR, "I" GIVING CALL-R
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.


    One of the things I've been testing in when reporting on large files is to get the environment var "TEMP" and copy the files to that directory, then set the "FILE-PREFIX" environment var to what is in "TEMP", then run the report files from the local temp directory. Reports that normally take 5 minutes to run across the network take less than a minute to copy and run.

    It's amazing to see that when copying files across the network, I see 50 to 60 % throughput on the Task manager network connections, yet when reading files across the network, it is always less than 10% throughput. We are using a 100mb network.


    First I get the current working dir to see if I'm working across the net or not.

    MOVE SPACES TO CurrentWorkingDirectory
    CALL "C$CHDIR" USING CurrentWorkingDirectory

    If the first character of "CurrentWorkingDirectry" not = to "C" or "D" then I assume that we are connected to a network.

    IF not (CurrentWorkingDirectory(1:1) = "C" or "D")
    perform Set-For-Net.
    perform Open-Item-Data.
    Perform Process-Report.

    Set-For-Net.
    accept temp-dir from environment "TEMP".
    set environment "FILE-PREFIX" to temp-dir.
    INSPECT TEMP-DIR REPLACING TRAILING SPACE BY NULL
    STRING
    TEMP-DIR DELIMITED BY NULL,
    "\\ITEMDATA" DELIMITED BY SIZE
    INTO TEMP-DIR
    INSPECT TEMP-DIR REPLACING TRAILING NULL BY SPACE
    CALL "C$COPY" USING "ITEMDATA", TEMP-DIR, "I" GIVING CALL-R
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    One of our customers has had a kind of similar problem where when generating a report, the report was taking a very long time to complete, especially when being run across a server. This report involved a lot of reads of a particular file. After reading sthoge's post i thought id try opening the file for I-O instead of INPUT, and it worked!

    Befor this fix the report took approximately 5 -7 minutes to complete, after the fix it took only 30 seconds. all i did was open the file as I-O instead of INPUT.

    However, the fix worked for runtime version 7.02 but doesnt work for 8.1, which still is very slow. I havent been able to test other versions.

    odd.


    One of the things I've been testing in when reporting on large files is to get the environment var "TEMP" and copy the files to that directory, then set the "FILE-PREFIX" environment var to what is in "TEMP", then run the report files from the local temp directory. Reports that normally take 5 minutes to run across the network take less than a minute to copy and run.

    It's amazing to see that when copying files across the network, I see 50 to 60 % throughput on the Task manager network connections, yet when reading files across the network, it is always less than 10% throughput. We are using a 100mb network.


    First I get the current working dir to see if I'm working across the net or not.

    MOVE SPACES TO CurrentWorkingDirectory
    CALL "C$CHDIR" USING CurrentWorkingDirectory

    If the first character of "CurrentWorkingDirectry" not = to "C" or "D" then I assume that we are connected to a network.

    IF not (CurrentWorkingDirectory(1:1) = "C" or "D")
    perform Set-For-Net.
    perform Open-Item-Data.
    Perform Process-Report.

    Set-For-Net.
    accept temp-dir from environment "TEMP".
    set environment "FILE-PREFIX" to temp-dir.
    INSPECT TEMP-DIR REPLACING TRAILING SPACE BY NULL
    STRING
    TEMP-DIR DELIMITED BY NULL,
    "\\ITEMDATA" DELIMITED BY SIZE
    INTO TEMP-DIR
    INSPECT TEMP-DIR REPLACING TRAILING NULL BY SPACE
    CALL "C$COPY" USING "ITEMDATA", TEMP-DIR, "I" GIVING CALL-R
    D

    [Migrated content. Thread originally posted on 18 June 2009]

    We set up our clients to run from a mapped drive. The we simply open indexed files from that mapped drive.

    I am seeing a strange behavior when reading data. We have a couple of programs that utilize some of the same code to display a list box of records that the user can interact with. The data files that this data is pulled from can have upward to 100k records in it.

    Our issues showed up when a customer called and complained that the client processing was extremely slow, but the application server pc (The one everyone maps to) worked normal. Of the two programs mentioned above, one worked fine displaying the data and the other did not. In our lab what I found was that the one that worked ok would take approximatly 3 to 5 seconds to fill and display the list box, whereas the program with the problem took 1 minute, 25 seconds to display the same exact information.

    Ok, now here's the weird thing that I can't figure out. The difference between these two programs is that one allows you to edit information in the file and the other is simply a report program. The one that allows you to edit the program opens the file for I/O and the report program opens it for INPUT. the confusing part is, it's the one that opens the file for INPUT that is extremely slow.

    I have verified that opening the file for INPUT is the culprit by changing the report program to open the file as I/O, then it will work as the edit program does in that it only takes 3 to 5 seconds to read and display the information.

    Am I missing something here? We have a 100mb network and the one that reads with the file open for I/O hits about 16 to 20 % bandwidth where as when reading the same exact data with the file open for INPUT only hits 7%.

    Any help here would be appreciated as I don't want to have to go through a couple of hundred different reporting programs to change how they open files.
    I stumbled across this helpful thread.

    http://www.acucorp.com/support/supported/customer_forum/showthread.php?t=1318

    I tried DougP's first suggestion

    "First, add this entry to the Runtime configuration file:
    NT_OPP_LOCK_STATUS FAST"

    This config entry worked for me, and this way i dont have to open files as I-O when they should be opened as INPUT.

    This worked great for me, so i didnt try the 2nd suggestion. :cool:

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement