Error 52, Bad file name or number

[ekimrepeel]

We have a DLL which has been running solid for years. We had to modify a function in one part of the DLL and now an unrelated function is throwing the above error when we attempt to:

intFileNum = FreeFile()
Open strFileName For Binary Access Read As #intFileNum

Suddenly, this part of the DLL can't open the file. Other than the unrelated function, nothing has changed. Have checked permissions, no change to the network or servers, the file it is attempting to open exists and can be opened from the Start -> Run menu item in Windows. I have tried changing the function signature by adding an optional parameter, have unregistered and re-registered the DLL...everything I can possibly think of, I have tried. I'm out of ideas. Does anybody have suggestions of why this has suddenly gone bad for me?

Thanks for reading this,
Mike

[RhinoBull]

... the file it is attempting to open exists and can be opened from the Start -> Run menu item in Windows..

Did you verify actual value of strFileName variable when code is executed?
At debuging time you can print it to debug window or pop the message box at run time...

[ekimrepeel]

In the error handler block, we return a variety of information including the filename:

ReadBinaryFile = "Error: " & Err.Number & ", " & Err.Description & " (Line " & Erl & ") | File Name: " & strFileName & " | File Number: " & intFileNum

The filename it returns appears to be valid - "\\vpdevsql\vp_share\download_requests\14_15519_3_1.zip" - which is what we expect to see and which opens just fine when we put it in the Start -> Run menu. Like I say, this has been running like a champ for years until we changed a different function in the DLL. How the bleep can changing a function in a DLL break a different function in the DLL? The rest of the functions in the DLL appear to execute just fine. I even changed the signature of the function by adding a parameter and that didn't seem to help...

Please let me know if I can supply more or better information. this is a real stumper for me.

[RhinoBull]

When you compile your dll make sure proper "Version Compatibility" is selected (Project menu>properties>component tab):

Version Compatibility

Allows you to set the level of version compatibility

No Compatibility — Compatibility not enforced.

Project Compatibility — If checked, the Location box is active and allows you to search for the file with which this project is to be compatible. If cleared, the Location box is not available.
For all ActiveX project types, Project Compatibility is checked by default.

Binary Compatibility — Useful for maintaining compatibility among projects that have been compiled using your component.

[ekimrepeel]

When I compiled the changed function I had to turn off Version Compatibility since the signature of the new function differed from the old one. Once the DLL was compiled, I turned Binary Compatibility back on, where it was set prior to the new code, and recompiled.

Is there something I should have done differently? I received the "Break Compatibility" message because I added a couple of params to the new code. How would I keep Binary Compatibility even though I changed the signature of the new code? I unregistered and re-registered the DLL after I recompiled.

Thanks, by the way, for your help. Your prompt response is appreciated.

[ekimrepeel]

Found the problem -- had to unregister the DLL, stop component services on the server, delete the component from component services, add the fresh DLL as unregistered component, and restart component services. Only took two days to figure this out!

Thanks for your help,
Mike

[RhinoBull]

Sorry I couldn't get back earlier so I'm glad you solved it.