Subject Re: [ib-support] --* Please Help*--- Database corruption and cannot backup & restore
Author Nando Dessena

> >all right, but let me emphasize that the path string is not incorrect,
> >it's just a *relative* path string, and as such conforms to the MS-DOS
> >specification.
> I'm not sure that's correct. I thought the RPA format was .\ and ..\ in MSDOS.

Almost. '.' and '..' actually, as the '\' is not required (which is the
source of our headaches).

> It's immaterial, anyway, as IB never ran on MSDOS. Whatever is "valid" in MSDOS or Windows, none of these formats is a valid format for connecting to IB.

I should have said that since the specification is inherited by FAT,
FAT32 and NTFS for compatibility, it's not that immaterial! ;-)

> Mapped drives are also not valid.

A completely different story. The docs say the database file must be
local to the server (al least I hope they do! ;-)).

> The documentation is quite explicit that the path must be the full physical path to the database file.

Right. But "full" does not always mean "absolute". A relative path is as
valid as an absolute one. In fact, I could run a database with dozens of
concurrent users all using the same relative path, and all would work

> I don't have a problem with that but I do have a problem with the ambiguity being able to pass across the client threshold.

In fact, I think that avoiding relative paths is a sensible
recommendation. 99.99% of the user base does not need them. What I was
questioning is the cause: an IB bug, not Windows' which works as
designed, and I was trying to explain why it was designed like that.

I have had my share of problems with ambiguity in connection strings, I
know the risks.