Hi Jeff,
I would almost suspect some "PATH magic" going on here. Do you have paths
defined that may conflict with the re-partitioned world?
In this situation, you may have old paths pointing to non-existant
directories if it does not find a command in your current directory.
("G:\whateverpath" no longer exists. It may get stuck there and never get
to you C:\rbfiles you have later in the path.) Otherwise it may find a
like name file in another app or another version of Rbase stored
Lord-knows-where.
Just an idea.
Also, I do not remember if this is RBwin, but a Windows program that is not
uninstalled before having its' world re-partitioned may leave some bad
artifacts in the Windows registry.
The same could exist for environment settings, scratch settings or virtual
memory.
Ike
At 07:15 AM 6/21/01 -0500, you wrote:
>To All,
>
>Thank you for all of the answers to my interesting
>problem. Unfortunately even with great help from RBTI it is still occurring.
>
>What the network people did was to combine partitions on the
>workstations. The client has older compaq's that have a c,d,e,f, and g
>drive. He left the c drive along but combined the d,e,f,g FAT 16
>partitions into one NTSF large d drive. Of course this wiped R:Base (and
>other programs) off the system so that's why I had to reinstall it.
>
>The C drive is left with 800 megabytes of space the D drive has 8
>gig. They upped the viritual memory for the D drive. The environmental
>variables still point to C: (tmp = c:\temp and temp = c:\temp).
>
>I tried running the database all locally and still had the same
>problem. What I did notice was the the problem always occurs at the same
>memory address - 0x004ad129.
>
>I really hope this sparks someone's memory of a solution. Thanks again.
>
> Jeff
