>Hi all
>
>I have a client who used my app as a single user and there were atleast a couple of times when the remote views were corrupted(?) and ended up replacing the serial number field value with, say the previous rows value, thus loosing the current value and ending up as a duplicate serial numbers for many rows. This is not the PK so records were identifiable.
>
>This is a supposedly a unique value but being an old app when I was foraying into Remote Views and FireBird I don't know why I have not implemented unique constraints on the back-end.
>
>We then did a reinstall (after recompiling the app for framework updates but not to the database and RVs) which recreated the RVs. We corrected the serial numbers and things are fine since then. Now they installed a node of this app (the new compile mentioned above) and the first thing that happened on the node is corrupted views and some of the data-entry forms (views) came up empty and others showed data properly. I made him recreate the RVs and things were fine again.
>
>What might I have done wrong or is going wrong. Please let me know.

No idea as to where things may have gone wrong, but if you have a views-only dbc, you can give each user a copy - you already have the code to create it from scratch, so why not do it on user's local directory? The app would be a tad faster, too, because every time you open a remote view, they hit the dbc; now they'd hit their own.

The time to create a dbc may not be negligible - YMMV. Eight years ago, when I last had such a problem, I set the code to make new local dbc whenever the loader detected a new version of the exe, so it would be part of a "you have a new version, let me make sure your settings apply to it" bit of the installation routine, so the extra dozen seconds (or up to a minute on the then 200MHz machines and big DBF files) weren't confusing the user.