Hi John

>Another issue: secure communications (SFTP, FTPS, local certificates, web services). Here I strive to use finished components, and with vfp I encounter somtimes COM problems not found in other languages.
>
>I don't think certificates etc have ever been VFP's forte. ;-) If you really needed to do it, maybe you could try the Etecnologia NET Extender with something like PowerTCP or your own NET classes with System.Net.Security stuff... but I agree you'd have to stop and think hard about what you're actually trying to achieve. Unless you're into heavy data munging, the need to carve your own security always would have been a good reason to look elsewhere.

That was totally VFP (grown from FPW) package used in rather small parts of different state government agencies. .Net was at the time moving from 1.0 to 1.1 and issues were much more in the mist back then. Since the level of involved admins was described as "exeptionally flat distributed" or possibly poisson-distributed <g>, I implemented the certificates via winHTTP and in essence wrote a small XML-RPC handler I partially re-used for web services.
>
>What's the trouble you're having with web services, btw? We've used VFP for years to provide those with very few problems. Actually it's been *years* since I've even looked at that side of it, which tells you how reliable it is.

I won't try to put the blame on who defines the standard (it already is a mess) but communicating with java/AXXIS you get some cookie-type tracking/verification added to the message header, complex data types are the norm (just string the info together, but out of scope for the toolkit)... I was quite undecided on what to argue for (somewhat redundant vfp implementation, wrapping dotnet, Jacobing java since AXXIS was the target) and we decided for a bare-metal vfp implementation to be not dependant on java/dotnet to be correctly versioned and installed in each instance.
>
>Re the issue of VFP "barfing" with lots of memory- I knew about the issue in Message #882003 but you're saying there's something else? Not good. Can you provide details? I'm assuming this isn't related to the weird issue of SYS(3050,1) returning a negative number in VFP8 on a machine with 4Gb?

Bad behaviour:
vfp unable to load a fll clearly visible via adir()
verified: the machine can "see" and load the fll in another new and pristine process
verified: happening to a number of different fll's, including a local Foxtools
observed but not really gotten into detail:
if continuing after first error (zipping fails), other well tested routines fail as well:
changing info in ini-files, printing via Amiyuni (unable to load printer driver ?),
where I *suspect* declare dll failed for the ini-change issue.

working off the same data sets and compiled program versions, the largest data set shows the behaviour running on 2 machines in all tests with no or MaxMem>=512 on a 2 and 3 GB machine, shows no error on "smaller" data runs even with no maxmem on both machines, but also shows no error if running the big dataset with the boot switch MaxMem=512.

Sys(3050) is massaged sometimes during program run, at start by the framework used and dynamically at the very start of "my" program - but memory is usually set between 96 and 192 MB in both foreground and background (but sometimes raised bracketing SQL-queries, reindexing, packing and so on).

Calls are coming from a bindevent()-situation on a destroy: shouldn't be a problem but not really typical.

Retesting with fixed sys(3050) as well as running under even smaller maxmems needs to be done before writing a bug report. Anecdotal: heavy SQL-processing sometimes puts vfp in a similar non-responsive way according to a coworker also heavy into data-slinging, but he had not encountered a systematically reproducible situation.

AFAIR I only log working set size via WinAPI but never actively change it, but I must verify that as well (the many cooks problem...)

regards

thomas