Very strange problem - ideas needed

[TimStone]

I am looking for ideas on where to look regarding this problem. It is very strange. I will provide detail and perhaps someone will have an idea what might cause this result. IT IS NOT IN FWH or my code, because it works EVERYWHERE except one location.

1). The problem: A routine looks at a record in File A, and gets a account number. It then looks at File B and totals the amounts for that same account number. For each occurence, as it totals, it marks the matching records in File B as complete.

2). It then adds the total amount of those records ( accumulated as each one is read ) to an existing amount in File A.

3). In this case it is not updating the file in Record A, but does everything else exactly.

What I have tried:

1). I tested the data files from the company on my computer and it worked fine. Conclusion: The files are not corrupted
2). I suspected an issue with the network, or server ( underpowered ), so I moved the data files to a stronger computer, and ran the operation on that same machine. It still did not work
3). I looked carefully at the code and can find no triggers for this.
4). There is no "apparent" security software. Direct editing on the file works, so it's not a read only file.
5). I ran the procedure for two months of data ( 2 times ) on my computer with their files and it worked perfectly
6) I transferred the file A from my computer after it had updated successfully to their computer. We then tried running the next month and it wouldn't write the totals from File B to File A.

Their computer is running Windows 10, a 1TB hard drive ( perhaps 30% utilized ), 8 GB of RAM, and an Intel i5 processer. My testing computer is Windows 11, 16 GB of RAM, with a SSD and a disk drive. However, many of my clients who have no problems are using machines similar to this client's computer, and having no problems.

As developers we all run into strange problems from time to time. Hopefully someone can share discoveries they have made in the past that could give me places to look.

Thank you for your contributions.

[Antonio Linares]

Dear Tim,

Could you show us the code you use to do it ?

thanks

[VictorCasajuana]

Cada iteración del registro B actualiza el A? O hace un sumatorio y lo actualiza al final?

Enviado desde mi motorola edge 20 mediante Tapatalk

[TimStone]

IMPORTANT: This is ONLY happening at ONE location. All other locations, and my test equipment can process the same code perfectly. Also this code has been working fine for years.

Built with FWH 22.06, Harbour, Visual Studio Community 2022

Here is the actual method used:

Code: Select all  Expand view  RUN

METHOD PeriodClose   CLASS tLedgerService
    // Perform an interim closing for a specific month
    //  Updated:    8/26/2015 11:03:37 AM
   
    // Declare EXTERNAL variables
    MEMVAR aSYSINI, oWnd
    // Declare LOCAL variables
    LOCAL oDlgGLC, aMonth  := { "JAN", "FEB", "MAR", "APR", "MAY", "JUN", "JUL", "AUG", "SEP", "OCT", "NOV", "DEC" }
    LOCAL aYear := { "2025", "2024", "2023", "2022", "2021", "2020", "2019", "2018"}, lRunClose := .f.
    LOCAL cGENNUM, nMONBAL, nGENDBT, nGENCRD, nGENEBL, oDba, oLedgerData
    PRIVATE aGLClose

        // oLedger is already open within the GL class ( AGLACT )
   
    // Load the static array values
    aGLClose := ARRAY( 10 )
    aGLClose[ 1 ] := "    "
    aGLClose[ 2 ] := "   "
    aGLClose[ 4 ] := aSYSINI[ 9 ]
    aGLClose[ 5 ] := .F.
    aGLClose[ 6 ] := SPACE( 6 )
    aGLClose[ 7 ] := .F.
    aGLClose[ 8 ] := .F.
    aGLClose[ 9 ] := .F.

    // Be sure the analysis was run and the accounts are in balance
    IF lOKtoClose = .F.
        lGLDoCLose := MsgNoYes( "You do not have a balanced analysis.  Do you wish to close anyway ?" )
    ELSE
      lGLDoClose := .t.
    ENDIF
   
    IF lGLDoClose
        // Create a dialog for the closing display
        DEFINE DIALOG oDlgGLC RESOURCE "GLCLOSE" BRUSH oBrush transparent OF oWnd
        oDlgGLC:nHelpId := 73
        // Create edit control
        REDEFINE COMBOBOX aGLClose[ 2 ] ITEMS aMonth  ID 1525 OF oDlgGLC ;
            MESSAGE "Enter the first three letters of the month you wish to process"
        REDEFINE COMBOBOX aGLClose[1] ITEMS aYear  ID 1524 OF oDlgGLC ;
            MESSAGE "Enter the year you wish to process"
        // Create button controls
        REDEFINE BTNBMP ID 1521 of oDlgGLC PROMPT "Process" RESOURCE "HROK";
            ACTION (lRunClose := .t., oDlgGLC:end())  MESSAGE "Begin processing for this month and year" NOBORDER TRANSPARENT
        REDEFINE BTNBMP ID 1522 of oDlgGLC PROMPT "Exit" RESOURCE "HREXIT";
            ACTION oDlgGLC:end( ) MESSAGE "Exit from this screen" NOBORDER TRANSPARENT
        // Activate the dialog
        ACTIVATE DIALOG oDlgGLC CENTERED
   
      IF lRunClose
            // Define the field for the month
            aGLClose[ 3 ] := "c" + aGLClose[ 2 ]
            // Open the GL transaction database and set the index  AGLTRN
            oLedgerData := TLedgerData():New( 2 )
            nFieldPos := oLedger:FIELDPOS( aGLClose[3] )
            cPMonth := aGLClose[2]
            cPYear := SUBSTR(aGLClose[ 1 ],1,4)
            // Set the processing flag
            aGLClose[ 5 ] := .T.
       
            // PROCESS INDIVIDUAL ACCOUNTS
            oLedger:gotop()
            DO WHILE !oLedger:eof()
                // Show the account number
                aGLClose[ 6 ] := oLedger:gennum
       
                // Validate that this is a Debit or Credit account
                IF oLedger:gentot $ 'DC'
                    // Obtain totals
                    cGENNUM := oLedger:gennum + oLedger:gendpt
                    nMONBAL := oLedger:FIELDGET( nFieldPos ) // oLedger:FIELDPOS( aGLClose[ 3 ] ) )
                    nGENDBT := 0
                    nGENCRD := 0
                    // Compile totals
                    oLedgerData:gotop()
                    oLedgerData:seek( cGENNUM )
                    DO WHILE cGENNUM = oLedgerData:genact .AND. !oLedgerData:eof()
                        // If the record meets the criterion
                            IF ( SUBSTR( UPPER( CMONTH( oLedgerData:gendat ) ), 1, 3 ) = cPMonth  ) .AND. ;
                                ( oLedgerData:genflg = .F. ) .AND. ;
                                ( STR(YEAR( oLedgerData:gendat ),4) = cPYear )
                            nGENDBT     += oLedgerData:gendbt
                            nGENCRD     += oLedgerData:gencrd
                            oLedgerData:genflg := .T.
                            oLedgerData:save()
                        ENDIF
                        oLedgerData:skip()
                    ENDDO
                        // Calculate the account balance
                    IF UPPER( oLedger:gentot ) = "C"
                        nMONBAL += ( nGENCRD - nGENDBT )
                    ENDIF
                    IF UPPER( oLedger:gentot ) = "D"
                        nMONBAL += ( nGENDBT - nGENCRD )
                    ENDIF

// ********  THIS IS THE SECTION THAT IS NOT WORKING ... but ONLY AT THE ONE COMPANY.  It works fine on every other installation including our test site.

                    // Put the total in the month field
                    oLedger:FIELDPUT( nFieldPos, nMonBal ) //oLedger:FIELDPOS( aGLClose[ 3 ] ), nMONBAL )
                    oLedger:genlpd := DATE()
                    // Recalculate the ending balance
                    nGENEBL := oLedger:genbbl + oLedger:cjan + oLedger:cfeb + oLedger:cmar + oLedger:capr + ;
                        oLedger:cmay + oLedger:cjun + oLedger:cjul + oLedger:caug + oLedger:csep + ;
                        oLedger:coct + oLedger:cnov + oLedger:cdec
                    oLedger:genebl := nGENEBL
// END of section not working

                ENDIF
                // Save and skip
                oLedger:save()
                oLedger:skip()
            ENDDO
       
            // Close the databases and commit the write
            //oLedger:close()
                // Open the GL history transaction database and set the index
            oDbh := tdata():new(, "aglths",,.f. )
            IF !oDbh:use()
                RETURN nil
            ENDIF
            oDbh:setorder( "aglths" )
            oDbh:gotop()
            // COPY FILES TO HISTORY
            aGLClose[ 7 ] := .T.
       
            oLedgerData:gotop()
            DO WHILE ! oLedgerData:eof( )
                IF oLedgerData:genflg = .T.
                    oDbh:append( )
                    oDbh:blank( )
                    oDbh:gendat := oLedgerData:gendat
                    oDbh:gencom := oLedgerData:gencom
                    oDbh:genact := oLedgerData:genact
                    oDbh:gencrd := oLedgerData:gencrd
                    oDbh:gendbt := oLedgerData:gendbt
                    oDbh:genflg := oLedgerData:genflg
                    oDbh:save( )
                    oLedgerData:delete( )
                ENDIF
                oLedgerData:skip( )
            ENDDO
       
            // Delete marked records
            aGLClose[ 8 ] := .T.
            // Close the files
            oLedgerData:close()
            oDbh:close()
            // Notify that the process is complete
            MsgAlert( "The processing is now complete" )
        ELSE
            MsgInfo( "Prcessing was aborted")
        ENDIF
    ENDIF

    // Reset the flag so you don't process without running the analysis again
    aSYSINI[ 9 ] := .F.
    lOKtoClose := .f.

RETURN self

The field where the data is written can be cJAN, cFEB, cMAR, etc.  These are monthly totals.  AGLACT is the master General Ledger file.  AGLTRN is the transaction file.  

 

[ADutheil]

I can´t see anything suspicious in your code. Perhaps the executable file was somehow corrupted. I would try to recompile with an irrelevant modification and try to run under another name on my client's installations.

[hmpaquito]

Hi,

Perhaps filters on dbfs for that location

Regards

[TimStone]

The .exe is not corrupted. I actually copied a brand new file to that machine remotely with the same result.

Yesterday I copied their complete database set to my computer, ran the routine for the month that isn't working, and it performed perfectly.

I suspected the server, so I moved the install to a newer computer. I looked for some type of security software but they are only using the Microsoft Defender built into Windows ( that I can see ).

I can edit that file without a problem.

Their system worked perfectly until this build which uses FWH 22.06, but it works everywhere else where the same build is installed.

It is VERY strange ... I do appreciate all your thoughts.

[Jimmy]

hi Tom,

as i understand you have 1 x Workstation which make Problem while other Workstation work ?

so the Problemis not your App, Data or Server ... it is "the" Workstation.
i would say the Workstation have a Hardware Problem even when you say it have work "before"

change Port on Router
change Cable from Router to PC
if Router have WiFi try to use Wifi and not Network Card

check Environment of PC
check Driver Version
did you use STATIC IP ?

check RAM
check Temperatur of CPU ( FAN might be dirty )

check Syslog if you find some Information

... or if you have another PC to change

[TimStone]

Jimmy,

Originally the data was on a network server.

I moved the data files to a different computer, and it is the same one that is running the Client ( program ). So it is not a networking issue.

It could be something in the one computer, but I see no other issues, and the total progam is quite large, so there are a LOT of routines still running fine.

I have checked RAM, the drive, etc, and monitored all of them with the normal system utilities. There are no red flags. Those are all important, and likely causes, but because none of them indicate an issue, and I see nothing in the System Logs ( Windows ) showing errors, it becomes even stanger.

Thank you.

[Otto]

Tim, have you checked the read and write permissions of the user and the files?
Best regards,
Otto

[TimStone]

Otto,

That was one of the first things I checked. I also made sure the file, and directory, were not marked Read Only.

The file itself can be written to by the user. This is a General Ledger file, and some of the data is available to be accessed from the client program, and we have no problem doing that. So, though I did check permissions, if they were not present, she wouldn't be able to write anything to that file. That is not the case.

Also, I copy those files to my test computer, and have no errors running the process.

Next I'm going to have us run the process from a different computer. Though her computer appears to be good, it is the one variable I haven't yet isolated. She tried it herself, but it was after the process had been run, so all the transactions had been marked as completed, and thus nothing was picked up by the process. So I want to hit it fresh from a different machine. If it works, then we know we have a problem with her computer though it appears to be fine.

Tim

[mgsoft]

Hi

Have you checked the anti virus?

[TimStone]

That was my very first step. I have found Norton to interfere with installs many times, and even delete .exe files.

In this case, the only Anti=virus is Windows Defender ( default ) and it has no errors.

[Rick Lipkin]

Tim

When I ran large State IT shops back in the day .. my employees gave me the nickname of "Mr. Fdisk" .. and I have taken that same logic to the Computer Store where I work .. What I am about to suggest to you may have already done...

I have found when I have a tough computer that does "wacky" things ... I can sit and dink with the machine for days costing the Customer time and Money .. or just back up the user data and wipe the machine with a fresh install.

If you have not wiped and done a fresh install of the OS on the wacky machine .. I would definitely suggest wiping the hard drive and re-install a fresh version of the OS

Just my 2 cents ..

Rick Lipkin

[TimStone]

Rick,

Unfortunately the computer is in Colorado, and I'm in California. A road trip is not in the cards.

I'm going to try the next step using a different computer then the one they have been using. At that point, if it works, then we know something is wrong in that one computer that is the root of the problem.

When I do a computer OS rebuild ( backup, reformat, reinstall OS ) I prefer to reinstall the individual programs rather than restore a disk image ( which might still contain the offending software or issue ). I'm amazed that older computers, when completely reset and updated, and fresh installs of the applications, actually work amazing well, and last for a very long time.

When it comes to the hardware, they turn to an employee ( auto technician ) who considers himself an expert. He's rather defensive ... so that increases the challenge.

Tim