joyfullservice
commented
1 year ago Thought I think 2nd option is preferred, I can see how some users might be annoyed to find their file altered so the 1st option seems the best. 3rd option is definitely a no-go because that's just enabling users and not solving problems.
The other factor that I would consider here is what does the application interface support, right out of the box. Sometimes you can do something via code that you cannot (easily) do through the user interface. I don't feel a strong obligation to support an edge case that is technically feasible through code but not something a user would normally be able to do.
For example, if I select the same image file twice when adding to shared images, Access automatically renames the second copy to a unique name, even down to the embedded file.
I agree with your preference for the second option, with the additional suggestion that we could throw a warning (that displays on the console output, and is included in the log file) when a duplicate image name is detected during export. As you point out in your article, these elements are referenced by name anyway, so it is in the user's best interests to eliminate the problem in their database. We can even include a more detail description in a log file entry that directs the user to more details on why it is important to resolve these duplicate names in their database. This helps push them towards option one, but doesn't prevent them from using the tool in the mean time.
While a user might be annoyed to find that their database built from source does not contain the duplicate image, the add-in always creates a backup of the existing database before building from source, so they can get their file back if needed. In my experience there are some kinds of changes expected when you build a database from source for the very first time, especially if it has been upgraded through multiple versions of Access. That first build is one that you want to inspect very carefully, and save a copy of that last backup. Subsequent export/build cycles should have very little "noise" between builds.
I feel that the scope of this project is targeting the faithful reproduction of a normal Access database file. Of course there are always going to be unique and creative ways that people use them, and various hacks that might be implemented. If it's something we can easily support and doesn't add too much complexity, sure! But if it is something that isn't technically supported by the software interface, I don't feel a huge obligation to support it on the version control side. (For some of the extreme edge cases, there are always the RunBeforeExport and RunAfterBuild hooks that can be used to accomplish just about anything.)
This code will fail with error 457 ("This key is already associated with an element of this collection"):
https://github.com/joyfullservice/msaccess-vcs-integration/blob/88efd2ce5a6b6f60f5988f1d8c29124ff33a1a9c/Version%20Control.accda.src/modules/clsDbSharedImage.cls#L461
As I discovered before, it is legal to have multiple entries with same names. 🤦♂️ Normally, I would just delete the subsequent ones on the assumption that the Access UI will not surface those duplications.
We could:
Thought I think 2nd option is preferred, I can see how some users might be annoyed to find their file altered so the 1st option seems the best. 3rd option is definitely a no-go because that's just enabling users and not solving problems.