>I found that the "REQUESTS","","","MYCONFIG" call doesn't work at all, not just 'for backward compatibility' but it's totally broken. It ignores the configuration file!
>You *have* to use the FF_BATCH interface, which is fortunately not as slow as I'd expected.

I have only used batch cursors, you're right they're not that slow.

>Also in adding "page n of m" to the reports I ran into problems where the calculation of the number of pages was just WRONG but I suppose we could blame VFP for that?

I haven't tried that feature but I'm going to test it on 2.x to see if it's VFP

>Fails on ABBREV where alias for the table in the setup of the system was chosen as ABBREVIATIONS.
>When setting a filter and then running SHOW SQL, FF says "Expected to find ABBREVIATIONS.DBF" and is looking for ABBREVIATIONS instead of ABBREV.
>The SQL-select statement is correct, it looks like the code that validates my selection against the source table is at fault.
>Workaround: Edit data items, Filter Options, remove checking!
>Click on "Value must be in ABBREVIATIO|" (note the NS won’t fit
>)Click on "Button for list of values"
>This removes the checking and the query will preview and show SQL

Crass! Looks like you have to leave the descriptive name same as the DOS name which is what I did in my app...

>In FoxFire! "Function not registered" is coming from CALLFN() after a REGFN() failed where there was no error trapping for failure.
>G_GETPTH line 782 is the point of error
> It’s caused by the failure of the regfn() call a few lines above.
>It’s suspicious that the SHELL.DLL is being used, not WINAPI and also that foxtools is being used instead of the new DECLARE..DLL syntax.
>I could register the function successfully from the command window even though the current registration returned -1.
>Then the program worked.
>Workaround: Turn off all Excel functions in FoxFire!

I suppose they cannot use DECLARE syntax because of multi version/platform considerations. But my users are exporting succesfully exporting to Excel, that's weird!

>Micromega ship 1/Nov/95, MS ship 16/Dec/95.
>
>Replace FOXTOOLS.FLL file in FF30V\3xlibs with the MS version from \VFP and it works, fixing 3 bugs at a stroke !!

Thanks for the info that probably is going to save lots of headaches!


Looks though as if the situation is getting a bit out of hand for them:
Just installed FF 3.0+ for 2.x and VFP 5: Crashes immediately looking for drive D:!!!!. Their solution: Insert a CD on you drive (what if D: is not yout CD Drive?) or re-build the project on a workstation without drive D: Jeez!

Also, if you have 3.0 there's a bug in the Ask At Runtime programs that forces the user to enter twice a "REQUIERED" filter value. Fix is in 3.0+ and can be applied to 3.0 copyng FFASKRUN.PRG, FFFLTVAL.PRG and FFVALTBL.PRG from 3.0+.

I haven't really put it under a heavy multi-user load but works OK on a 5 user workgroup.