>>I thought I'd seen messages about a patch for this problem within the past few months, but I just failed to find anything about it by searching.
>>
>>You know the problem where, if you compile an APP or EXE in FPW 2.6 on a computer with a CD-ROM drive, and a user runs it on a computer with a CD-ROM drive, but they don't have a CD-ROM in their drive, they get an "Error reading drive (cd-rom):" error if certain FoxPro commands are executed (even though you don't specifically reference the CD-ROM drive in your code, because certain FoxPro 2.x/Win commands hit Win95/WinNT API functions which sequentially hit all drive letters or something like that.)
>>
>>I thought I saw that there was a patch to the FoxProW.exe which was supposed to fix the problem. Was I dreaming? Microsoft's KB has articles which refer to the problem (Q108165, Q120246) and suggest that you change all your users' CD-ROMs to drive Z: as a solution, but they don't mention a patch.
>>
>>If you know of a patch, I'd sure appreciate a reply, especially by e-mail, pointing me to it. I haven't been on the U.T. a lot lately, as some of you may have noticed.
>>
>>TIA,
>Hi Rich,
>
>The problem is caused by were the temp files are stored when the EXE or APP is compiled. If, for example, you have a D: hard drive (like I do), and for some (stupid BTW in my case) set the various config.fpw items to indicate a directory on that drive, any user that doesn't either have a D: drive or doesn't have a CD in a CD-ROM drive which is setup as D: will get this error.
>
>The fix is simple. First, make sure that TMPFILES, PROGWORK, etc. are set to a directory on your C: drive. Start FPW after making changes. Open the project as a table and from the command line issue: REPLACE ALL ObjCode WITH "". Close the project table. Open the project was you normally would do and re-compile.
>
>hth,

Thanks, George, but (I'm pretty sure) you're referring to a different problem. This happens regardless of where temp files are pointed on the compiling machine or the end-user machine. Config.fpw isn't involved in this problem. In my specific case, the problem apps were compiled on a machine with cd-rom D:, not HDD D:, and all temp file locations left as default (TEMP environment var if found, or Fox startup dir, correct?) On the compiling machine (and all workstations on this network, i.e. end-users as well) DOS TEMP var is C:\TEMP or C:\TMP. All workstations which use the Fox apps have Fox installed to C:\FPW26, too. So temp files on D: shouldn't be a factor here.

Check out KB articles Q108165 and Q120246. MS acknowledged this as a bug in EXEs created with 2.x Distribution Kit, and fixed it in 3.0. (It also affects APPs created with 2.x Distribution Kit, but the articles don't say so.)

Thanks for trying,
Rich.