Is there any reason why H is NOT root mapped? Ask him to root map it (or you can do it from a command line if you have the rights) and see if it resolves your problems. Of course, that may change your command in VFP pointing to the table locations. You may have to modify it unless you that the location is valid even if H: is now mapped to \. Was it mapped to the root of the drive when you login to Novell, but just NOT mapped using the codeword ROOT? That means the location of H: can change dynamically and could be a problem. However, why it was not a problem in VFP6 is beyond me. I never map drives from within VFP without ensuring that the drive in NOvell is root mapped because the dyamic changing of the location of a drive letter can be disastrous. I'm not sure if this is your problem, but you might want to test it and see if H: was dynamically remapped somehow.
Tracy


>I asked my administrator and he said our novell servers, H: is not root mapped and F: is root mapped. The I: drive, which is the NT server is root mapped.
>
>>But are they both root mapped? or is one root mapped and one mapped?
>>Tracy
>>
>>>Tracy,
>>>
>>>I'm doing this right from the command window. Both drives are mapped to sub-directories on different servers.
>>>
>>>>IF this STILL occurs AFTER you load SP1, stop the program via the debugger JUST before the mapping that fails and check your drive mappings from within the program right there. What is mapped at that point in Novell (via the NOVELL command MAP) for I and H? Run MAP|map.txt to pipe it to a textfile named map.txt and view it.
>>>>
>>>>Tracy
>>>>
>>>>>You lost me on the networking issue. The only thing I can say is that it still works in VFP 6.0. I have both installed on my machine. I will try installing sp1 after lunch, have to go home and get the cd.
>>>>>
>>>>>>Try it and see, because on my SP1 copy of VFP7, I did what you listed below witht he SET DEFA and SET PATH, and I was able to open tables along the path both with and without the leading backslash. The only difference I had was that my drive letters are P: and H:. My P: drive does not contain any of my DBFs, there are on the H: drive, so I set the default to P: and the path to H: and was able to access tables both ways.
>>>>>> The only thing that comes to mind is the way the Netware drives are mapped. If, for example, H: is mapped to SYS:HOME and NOT a MAP ROOT, H:\myapp\mytable.dbf is NOT the same thing as H:myapp\mytable.dbf (you can check that from a command prompt). One references a path relative tot he root of the SYS volume, and one references a path relative to the HOME directory on the SYS volume.
>>>>>>
>>>>>> Randy
>>>>>>
>>>>>>>I take that back...I was reading another thread and found out that my version 7.00.0000.9262 does not have the service pack installed. I am going to install it and try to re-create the problem.
>>>>>>>
>>>>>>>>Yes, I'm in a large network. F: & H: drives are both Netware and I: is an NT server. When I purchased VFP 7.0, Service Pack 1 was already out so I installed it right away. I'm not sure if this was happening before SP1.
>>>>>>>>
>>>>>>>>But, I must have not explained the problem correctly.
>>>>>>>>
>>>>>>>>If I just set the default drive like you did everything works fine. I can open any table in the default drive with or without the backslash. It's when I set the default drive to [I:] and then set the path to [H:] and try to use a table on [H:] that I get an error.
>>>>>>>>
>>>>>>>>SET DEFA TO 'I:'
>>>>>>>>SET PATH TO 'H:'
>>>>>>>>USE \SUBDIR\MYTABLE {DOESN'T WORK}
>>>>>>>>USE SUBDIR\MYTABLE {WORKS}
>>>>>>>>