FiveTech Support Forums

wrkdat displays as "999999" while the others display as normal dates.

oLbxo:oCol( 10 ):cEditPicture := nil

XBROWSER ::oOrders:aStruct

oLbxo:bRClicked := <||
    ? oLbxo:oCol( 10 ):cExpr,oLbxo:oCol( 10 ):cDataType, oLbxo:oCol( 10 ):cEditPicture
        return nil
    >

No problem. It is late but I will do those steps in the morning. Yes, it is strange, and unique, so I’m happy to do those tests.

The one client who had problems is running OS 21H2, so I asked him to run the Windows update.

Sent from my iPhone using Tapatalk

Good Morning,

I have run that on both computers.

On both computers xbrowser shows wrkdat as D 8

On the i7 computer, the right click displays wrkdat D

On the Virtual machine, the right click displays wrkdat D 999999

To clarify, although the dates are different for entries of wrkdat, the incorrect display shows 999999 for ALL rows regardless of the content of the wrkdat field.

I've also just encountered another issue with xBrowse but need to do further testing to be sure exactly what is happening.

Tim

On the i7 computer, the right click displays wrkdat D

On the Virtual machine, the right click displays wrkdat D 999999

I did build with FWH 12.07 and now it shows the same issue.

On the ARM machine ... it shows on the aStructure ... WRKDAT, D, 8, 0, , , 999999

On the i7 is shows as WRKDAT, D, 8, 0, , , , so no 999999

Just to be sure, I copied the entire data directory from the known good to the problem system and thus the files were exactly the same on both computers. Same problem

Finally I copied all of the files from the directory where the .exe resides, including .dll files, and suddenly it worked.

So ... my first step is to see if I can isolate exactly what .dll file might have been different.

On the ARM machine ... it shows on the aStructure ... WRKDAT, D, 8, 0, , , 999999
On the i7 is shows as WRKDAT, D, 8, 0, , , , so no 999999

Unfortunately, I think it got more complicated than that. First, clients who have the problem were not using ARM computers. I was able to see the problem using mine ( C2 below ).

Computer 1 ( C1) is my primary programming computer. I am running Windows 11, 23H2. Builds are done with Harbour ( 32 & 64 ), FWH ( latest versions ), and Microsoft Visual Studio Community ( latest builds ). It is a Dell Inspiron AIO.

Computer 2 ( C2 ) is a Mac mini, using the M2 processor ( ARM ). It has Parallels running Windows 11, 22H2 in a VM.

The data is stored in a MLS12s folder on the "server" which could be any type of machine, or for a single install ( not multi user ), it is on the same machine.

The Client consists of an .EXE, and multiple supporting files ( .lic, .ini, .dll, etc. ) placed in the MLS12c directory

I built the application and placed the primary .EXE in the MLS12c folder

1. I never observed the problem on C1, but did see it occur consistently on C2 using the exact same .EXE.

2. I did not see it with earlier builds using FWH1207. It did occur with 1210

3. I rebuilt the application using FWH 1207. The problem did not occur on C1, but did occur on C2

4. I then copied all of the data files from C1 to C2 so I could be sure it wasn't in a data file. I still got the same result with the error on C2

5. Finally I took all of the remaining files in the MLS12c folder ( Client ) and copied them from C1 to C2. Then the problem no longer occurred.

My mistake was that I did not first compare the two sets of files to see what was different. I do not appear to have a copy of the original set. I just know when I copied over those files, the problems went away.

So, now I'm trying to see if I have the set somewhere where I can compare the new vs the old ...

Meanwhile, people are getting automatic updates applied by Microsoft to their OSs. One client called to tell me he could no longer Cut and Paste in our program. It occurred a couple of days ago when I sent out the first update. When I asked him specifically where, he went back to check and it was suddenly working. He then remembered that Microsoft Updates were being applied in there also .... so it does get very hard to dig into this.

With all of that in mind, I'm quite happy to do any tests you might like ...

Dear Tim,

Is the problem solved ?

It seems as you missed to copy something. Is it so ?

Antonio,

The problem is no longer on my ARM machine.

However, my client says it is still on his Intel i7 Computer. That makes it even more complicated.

It is not that I missed to copy a file. It must be that some .dll on there wasn't current. However, those are fairly new installs ( within past 60 days ), and using all of the current install files, it also works on the ARM. So this is really tricky to solve.

Of course, we expect that with software .... and Windows

Tim

Dear Tim,

> However, my client says it is still on his Intel i7 Computer

Is it an apple computer ?

If not, what Windows version is he using ?

OK ... I HAVE ISOLATED THE PROBLEM.

Many of my clients, and some of my test machines, use Advantage Data Base Server. That is the root of this problem.

If I go to our DBFCDX RDD, absolutely no problem. If I turn on ADS LOCAL or REMOTE, using the ADS drivers ( all versions ), the problem described in the original post will occur.

I think I'll have to use a workaround to avoid this. I have many clients who use ADS Client Server, and paid a lot for the licenses. The product has not been updated since 2015, it is now end of life, and the company will not release it, nor do they provide an alternative. So there is no way to get any adjustment or fixes to that software, and we don't have a DBF supporting alternative.

I don't know if we can address this through a tDatabase update, or if it is more than that.

Tim

If the problem is with ADS, let us now test dbfs with ADS.

Meanwhile please download the latest build of FWH again.

We will proceed testing dbfs + tdatabase using ADS.

We "have" to make the class working perfectly with ADS also.

I will do some tests tomorrow here.

The files I have downloaded now are from 11/4 at about 11:30 am. Is there a more recent version ?

Dear Tim,

Yes, please download FWH again