On 02:32 PM 12/11/2001 -0500, Abd ul-Rahman Lomax said: >Yes, it is correctly called a "buglet." Protel commands inherently rooted >in one database should never write to files in another database, even if >they are open. Further, if, for some reason, the filename alone is going >to be used in a process, instead of a full name including the database >name, then checking should be done for the presence of duplicate files. In >this case, the damage is small, removing those scribbled error markers is >practically one-button. That might not be true with, for example, an >update from library, where it could be disastrous. >[EMAIL PROTECTED] >Abdulrahman Lomax >Easthampton, Massachusetts USA
I think it is a bug. Pure and simple. Those with long memories will recognize this as similar to the warning and loss of data that could occur when two like named but different pathed DDB files were being manipulated on a multiple machines on a network. The corruption occurred when one file was saved and the other user was prompted to reload the saved changes - thus possibly loosing uncommitted changes they had made. The similarity is that the software was working off name only and not the full path. I think it is reasonable that we expect that when a characteristic error is found in one part of the program, an assessment is made on whether that bug could exist in other parts of the program. That is certainly the sort of assessments we make in during our bug fixes. Maybe I am being a little unfair here, though. They may be quite unrelated (one is related to network traffic after all). It has taken quite a while for this bug to become apparent (to this list at least) so it is possibly reasonable to assume that the name-only matching is not wide spread throughout the program. Maybe someone in Protel R&D could assess this though... Those bored of my rantings should drop off here... Maybe the forum should have a poll on those users they wish would shut up most :-). This is especially wired as the SDK makes use of a full path names that burrow inside the hierarchical structure of the DDB - just like a disk file. So there is really no reason why a full path comparison should not be made. It is even weirder when you consider the Sch project iteration examples that are provided by the SDK - I would think it was difficult to make the mistake as to which Sch should have the markers as once the project is iterated, the example at least, uses a stored handle to access them - not the name. So I remain a little confused as to why the bug should occur at all. But I am sure there is a good reason for the current implementation. (Why am I discussing the SDK when the NDA has not been rescinded? This aspect of the SDK was part of the original SDK release, I "signed" the NDA for this part over a year ago so the 12 months timeout clause in the NDA has come and gone. Now the SDK *updates* for SP6 are still probably covered. Bit of a silly situation.) Bye for now, Ian Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
