I am having a strange JoinOneRecord error with only one client computer. All of our client computers operate remotely over the internet. I have seen this error before when we had to rename a field, but after re-establishing the relationship with the source database, the error did not return. In the current case, we also renamed one of the database fields, but we also re-established the relationship with the source database and then uploaded the changes to the server through a new generation. One anomaly is that the client computer having the problem is missing an auxiliary file that is showing up on my computer. This difference prevails despite multiple uploads to the server and downloads to the client computer. Alas, we won’t be able to test additional clients until tomorrow, but I thought I would reach out to see if anyone else has experienced anything like this.
I might be able to be of more help if you included the actual error message.
There are two errors that appear:
I believe the problem stems from setting up a relationship between two files and then changing a field name. That will produce the errors above. One must then go back and fix the relationship so that the field names are correct in the window. That solves the problem on the primary machine where the relationship was established. However, it appears that the changes do not make it to the server when performing a new generation. Although client computers synchronize or download new files from the server, the clients will incur the error messages as if the relationship was never repaired. However, if we move files directly from the primary machine to the client machines, bypassing the server, the clients can work without incurring the error messages.
When you did the new generation, did you choose the “Field Arrangement and Data Types” option? If you just used the “Field Properties” option, I don’t think that would be enough. Relationships are not part of the field properties, they are part of the overall database structure, which is only transferred if the “Field Arrangement and Data Types” option is used. If you use the “Field Arrangement and Data Types” option, that is effectively the same as moving the files directly from the primary machine to the client machines.
That makes sense. We are used to using Field Arrangement and Data Types for adding, deleting and changing field names. We forgot or did not realize that establishing and modifying relationships will require the maximum strength New Generation. We will use the Field Arrangement and Data Types option to upload our changes to the server and verify tomorrow that the clients are receiving all of the relationship changes made on the primary machine. There may be an unintended user trap here by not allowing adding fields, deleting fields, or editing field names without taking the database off-line, but allowing relationship changes on the fly much like procedure and form changes.
I think this could possibly be changed in the future to include relationship specifications to be transferred when a “Field Options” new generation is done. I have made a note of this possible enhancement. I am not guaranteeing that this will happen or is even possible, but I will investigate it.