1 Reply Latest reply on May 13, 2014 2:14 PM by philmodjunk

    Replace Field Contents - Communication Error



      Replace Field Contents - Communication Error


                I have a customer that I am creating new DB for, but until then, they are using their old one.

                They have this problem with their old one that when they do a Replace Field Contents it gives the error:

                "Communication with the host was interrupted and could not be re-established.  All affected windows will be closed."

                It only crashes when their one field is categorized by certain data.  If that field has any other data beside that one criteria (and they do a find to get that into a found set), then when they do a Replace, it does not crash.

                The replace is not being done on the one field, it is being done on separate field(s), which are repeating field(s).  It doesn't matter if the replace is being done in a large found set or only a couple records.  They can manually type into the field without a problem.

                They only have one table.  This layout does not use script triggers or hidden buttons.  If I create a new layout, and try to do the find on that one field, and then the replace, it will crash.  It won't crash other computers, but will crash individually on each, if performed on there.

                They have Windows and they are connected through a VPN.

                Both and the customer has posted on Forums.  The one solutions was to take it off the server, do a recovery on the file, and then upload it again.  That had worked, but only for a while.  The answer I was given was that either some other user had been in there when the Replace-Field Contents had been occurring or there was validation.  The fields don't have validation, and they have tried it with only one person in the system. 

                Any help is appreciated, thanks!


        • 1. Re: Replace Field Contents - Communication Error

               It sounds like they were given good advice on doing the recover. But the possibility that another user might have one of the records open for editing shouldn't result in a crash. That will "edit lock" a record and you'll get an error message that a record could not be updated, but it should not produce this crash.

               Best guess is that the file is damaged in some way that either the recover cannot fully repair, or some issue that originally damaged the file damaged it again at some point after the recover fixed it.

               Things to keep in mind about Recover:

               While Recover almost always detects and fully corrects any problems with your file...

          1.           The recovered copy may behave differently even if recover reports "no problems found".
          3.           Recover does not detect all problems
          5.           Recover doesn't always fix all problems correctly
          7.           Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.


               And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).