2009/12/28 Ricardo Aráoz <[email protected]>: > Hi all, > we are experiencing a weird behaviour in an app here. This is a vfp6 > app that performs a series of queries to a MSSQL Server (through odbc), > processes the received cursors and writes a few csv files. This app is > called from a few Progress front ends which then read the csv's and > processes them into the Progress database. > This app behaves properly everywhere (called by Progress front ends or > command line) except when called by a particular Progress front end > where it will return corrupted data (actually a field of the result set > is zero when it shouldn't). Logged the hell out of this vfp app, and > when called with exactly the same parameters from the command line or > when tracing it, the app will behave properly. > I am beginning to suspect there might be a memory corruption problem. > Maybe the Progress front end uses too much memory and corrupts the vfp > app's memory. Anyone ever heard of something along these lines? Any > suggestion/workaround you can think of? Is there any way of > limiting/protecting the memory used by the vfp6 app?
If you're running on any version of Windows from NT up, you should have good process isolation. Earlier Windows versions had a memory model based on the design of an ancient Roman bath house located near Mt. Vesuvius, but NT and up at least try to enforce process isolation, so one app poking around in another app's memory space is "theoretically" not possible anymore. I've encountered Progress in the past. Was not a good experience, mainly because our Progress "experts" couldn't design a data model that worked if their life depended on it. Unfortunately for them, other people's lives depended on it---but I can't blame the tool for that mess. I don't especially like the 4GL language, but had to write an implementation of the Levenshtein edit distance algorithm in it, to create a semi-manual custom-weighted human-name duplicate identification process (because the data model sucked wind and we could not uniquely identify records in our most important table). It was fun, like trying to carve an ivory statue of Medusa with your bare hands and bleeding fingernails. The problem may be in the ODBC driver. If both Progress and VFP -- separate clients using the ODBC interface, my guess -- can reproduce this problem, there may be a DLL-hell version issue in terms of the ODBC client. That is a total stab in the dark. I'd like to know more about the specifics of the calls being made respectively by both apps that demonstrate the problem. Also, to track down the problem, it may help to run this while reproducing the problem: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx I recently learned about that tool, and cannot imagine system-wide debugging/troubleshooting anymore without it. - Publius > > TIA > > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
