TOPIC:

I've been using an old Visual Foxpro 6 browser and now having difficulties with DBFs indexed in X#. (Can't modify structures.) I checked the date on this VFP6 app and it's 1998, which means it's about time to switch. What does everyone else use?

Although I'm trying to make the switch from DBF to SQL, I'll still inhabit the DBF world for awhile.

And while I'm on the subject, where does one acquire a legal version of Visual FoxPro ?

OhioJoe wrote: I've been using an old Visual Foxpro 6 browser and now having difficulties with DBFs indexed in X#. (Can't modify structures.) I checked the date on this VFP6 app and it's 1998, which means it's about time to switch. What does everyone else use?

vfp9 is stable and fast if you already vfp and/or need to port/enhance existing app.

Although I'm trying to make the switch from DBF to SQL, I'll still inhabit the DBF world for awhile.

Local DBF is still great if you can live with [hard to encrypt / easy to fudge with excel].
Multi-User DBF on a [server] file share is too dangerous now as MS f*cked up SMB for good - even if you get error free running for a time, any Windows Update can screw the App into Fubar.
Go to vfp9, use cursoradapter until app runs on previous dbf, then switch over to one of the C/S SQL server backends.

And while I'm on the subject, where does one acquire a legal version of Visual FoxPro ?

Either from an old coder going out of biz or via MS developer bundle. Old coder on ebay I'd be careful, old coder found on forum I might trust.

regards
thomas

Microsoft have not 'f*cked up SMB for good'. They occasionally break something in an update meaning that things like Visual Foxpro and MS Access have corruption issues - the last time was in 2018.

We have hundreds of sites running Visual FoxPro with DBFs under current Windows 10 releases with no issues.

That's not to say that DBF is a good choice going forward of course.

SMB is orders of magnitude faster than it was 10 years ago - we have sites that crawled on Server 2008\Windows 7 that upgraded to Server 2019\Windows 10 and it's like night and day in terms of speed.

Bourke wrote: Microsoft have not 'f*cked up SMB for good'. They occasionally break something in an update meaning that things like Visual Foxpro and MS Access have corruption issues - the last time was in 2018.
...
SMB is orders of magnitude faster than it was 10 years ago - we have sites that crawled on Server 2008\Windows 7 that upgraded to Server 2019\Windows 10 and it's like night and day in terms of speed.

Sorry, in my book a protocol has to work correctly before thinking about speed.
SMB1 caching only if single user had file open was at least dependable - even if speed broke down a lot (esp. on last century 10MBit networks) whenever 2nd user opened file. Since SMB2 you have to depend on having correct registry settings, which MS Update might change anytime they feel like meddling.

SMB since ver.2 is not dependable for multiuser ISAM access, SMB1 today is an auth security risc.

F*cked up in my book or do they now support a way to *guarantee* the safe registry entries either totally or for a subset of shares / dirs / files ? ISAM usage pattern is markedly different from the "document" usage for Word or Excel later oplocks tweaks try to optimize for.

my 0.22€
thomas

"Since SMB2 you have to depend on having correct registry settings,"
"SMB since ver.2 is not dependable for multiuser ISAM access"

Other than having to change caching settings for some machines for a while in 2018\2019, this is not our experience with hundreds of multiuser sites using VFP application with DBF files.

On Server 2019 you can set SMB caching settings on a per-share basis.

ISAM databases are now very much a corner case in SMB terms. SMB is at the heart of every Microsoft-basednetwork in the world - obviously it works extremely well in almost all circumstances otherwise they wouldn't have a business.

Bourke wrote: "Since SMB2 you have to depend on having correct registry settings,"
"SMB since ver.2 is not dependable for multiuser ISAM access"

Other than having to change caching settings for some machines for a while in 2018\2019, this is not our experience with hundreds of multiuser sites using VFP application with DBF files.

On Server 2019 you can set SMB caching settings on a per-share basis.

ISAM databases are now very much a corner case in SMB terms. SMB is at the heart of every Microsoft-basednetwork in the world - obviously it works extremely well in almost all circumstances otherwise they wouldn't have a business.

My original statement was:

Multi-User DBF on a [server] file share is too dangerous now as MS f*cked up SMB for good - even if you get error free running for a time, any Windows Update can screw the App into Fubar.

which is the not-PC way of saying the embolded part of your post. Yes, if the user of your app has admin rigths to be able to correct any registry settings changed, the danger might be lessened. Of course adding each user into admin pool does wonders for your network security.

Perhaps your persistance writes occur seldom enough and you controlled MS Updates well enough - IMO still a time bomb and reason to fine you for negligence if data mishap causes large client costs. Look at SQLite, which is a ISAM as well - read up on single user write lock to allow network access from SMB clients. The only way I will implement SMB write persistance on dbf/fpt/cdx is via exclusive access. Not too hard to implement on generalized basis if client does not want to install DB server. I am well aware this opens up locking scenarios we all hoped to have left behind when optimistic locking was introduced and is clearly less granular compared to even SQLite unless a bit more is invested in open logic, but with a cursoradapter pattern of reading server files, detaching result cursors and closing those tables ASAP it is possible to still use server/SMB dbf, but that is NOT multi-user access any more. As free versions of C/S SQL servers most of the time can handle data requirements and free offerings like Postgres and MariaDB exist, not using C/S backend or pattern described could make me liable. No way, as insurance would be polite but strict in refusing coverage if I did not use known best practices...

Win10 disallowing SMB1 for the broadcast/security reasons was necessary. Not having a fallback to the SMB1 secure way of handling caching/oplocks for file server ISAM is a f*ckup in my book. You might google for Oplocks / SMB data corruption - even MS acknowledges the possibility. ISAM vendors (still depending on Windows) describe "the corner case" you spoke of in more detail, but politically correct. I see no need to try for PC here.

my 0.22€
thomas