Problems after importing a form

[silverback]

Question about Access 2003 and importing.
I develop things at home and then deliver a dummy database to my user who deletes various objects in his DB and imports the updated objects from my dummy DB.

In his DB, he has a form with an unbound list box which lists employee names. The SQL is held in the RowSource line and it is SELECT EmployeeID, Trim([LastName] & ", " & [FirstName]) FROM....
In his version of the form, ID is not displayed; it is column one and the bound column, but has 0cm width.
In my updated version, he wants the ID displayed in case two or more employees have the same name. The display is to be Name then ID.
I've reversed the SQL so it now says SELECT Trim([LastName] & ", " & [FirstName], EmployeeID FROM ..... and changed the list box to a) display the ID by giving the column a width and b) changing the bound column to 2.
All works fine in my DB.
However, when I try a sample installation and import the new form, the data is displayed ID then Name, even though the RowSource is as above! Totally baffled, I clicked into the RowSource line and then clicked on the ... symbol at the end. The query design view showed that the fields were in the order I required. I closed the design view and all the other dialogue boxes and then was asked "Do you want to Save Changes?" What Changes? I haven't made any. Answering Yes, the next time the form was opened, the data was the right way round! I've repeated this several times, so it wasn't the fact that I'd had a lot of funny juice.
Any ideas, please?
Silverback

[HansV]

Access keeps the row sources of all list boxes and combo boxes in a hidden system table; this should be updated automatically but apparently it wasn't, so the form still used the old row source.

Clicking the build button (the ... at the right hand side of a property) counts as a change, so that's why you were prompted to save the form.

[silverback]

Thanks - I thought I was going nuts.
What table is it in? I've exposed the Hidden Objects and System Objects, but there's nothing in those tables that looks like row source.
Silverback

[HansV]

It's stored in the MSysObjects table, but the row source is stored in a binary field, so you can't read it.

[Mark L]

This is about as annoying a problem as you will find. At a company I do contract work for, we call it the "Access is Stupid" error! There are 3 programmers who maintain the database. As obviously we can't all be working on it at the same time, we each have a copy and have an automated process in which in which we submit the objects that we changed to the master database at which time it archives a copy of the old objects and checks the Last Version Date of each object to avoid overwriting changes by another programmer.

We have tried all sorts of contortions to get around this, but nothing seems to work. Basically, we have to warn the programmer who is responsible for running the update process that there is a potential for an "Access is Stupid" error on a given control, so she can open/close the rowsource for that control so Access recognizes it.

Since the frontend is pretty large (100mb), we had considered using this automated update procedure to keep the clients updated. But the "Access is Stupid" error makes this impractical, so users must download the entire 100MB db to get updates.

[silverback]

Wow - I thought I had problems!
It's probably not a practical idea for your situation, but my wife and I did think that changing the name of the object being imported would prevent the error. In my case (small DB, four users!), changing the name of the form being imported would only require one other change, this being to the switchboard that calls the form. I guess that in your corporate situation this won't be a practical option, but just thought I'd mention it.
Silverback

[Mark L]

Wow - I thought I had problems!
It's probably not a practical idea for your situation, but my wife and I did think that changing the name of the object being imported would prevent the error.
Silverback

Thanks, but this is not possible in situation we have, as forms are often called from other forms (not merely from a switchboard), forms and reports reference controls on other forms, etc. Also, I'm not sure it would work anyway. The import process deletes the object before the changed object is imported, and even then we have problems.