Hi Mike,
>
>Im following a process memory.
Ok.
>I have created around 6 vfp cursors in the load event of my form. In the click event of the process button, I executed 2 SQL Pass Through commands that fetches records from my SQL Database.

*Probably* unneccesary, but to eliminate complexity I'ld move the critical process into simple prg's, which can be called from the IDE.

Then I'ld open the connection, fetch the records and get my first measuring point.
Then close the connection and see where I am, perhaps writing out the selected records from a cursor into a table I am able to close/disconnect. Also don't forget to close the connection.

>After the records are fetched, I analyze the data and insert viable information in the vfp cursors.

Only here I'ld create the next cursors needed for analyzing and fill them. Also I'ld implement a switchable "cursorcreate" to enable you to work on tables or cursors with a simple flagchange. Again, probably unneccessary, but a possible way to reduce memory allocation.

>It is in the inserting process where the memory leak occurs.
If it is a real leak, check for object use: any dangling pointers en masse ? Work as closely as possible to FPW(!) code in your insertion process.

>I also tried releasing the parameters passed in my insert event at the end of the event and I also tried releasing the vfp cursors in the unload event of the form.

Since no form is involved in my test schema, you best create a "cleanup" function to run before the measuring point where you expect everything to be back to normal. If everything clears, you can easily hook your prg's into your existing form.

Since everything should be able to run from locally persisted tables, as a last resort close vfp down between the steps - this might give you warning about false assumptions on your part.

HTH

thomas