November 30, 201015 yr Hi Guys, I'm scratching my head over this one and its probably something simple, I have multiple clients, some winXP and some Win7 running FM11, all connecting to a single database via server11 on a Win7 machine. We seem to loose random data from fields, usually within tabs, one minute its there the next gone! not all records have this issue so its completely random - Im just not sure where to start looking for the problem. Thanks Samantha
November 30, 201015 yr First be sure users are connecting correctly through Open Remote. Second, close file on server, stop FMS services, and open file in FileMaker Pro and run a consistency check on it. Do not recover it. See what the log says then. This sounds like a possible corruption issue. BTW, Windows 7 is not a good OS for FileMaker Server. Steven
November 30, 201015 yr Are you sure that there is only one copy of the databases on the network? If there is another copy of the files on a workstation, it's quite possible that someone is connecting to the wrong set of files. Which is the same idea as what Steven had.
November 30, 201015 yr I'll second Brent's suggestion! Change the production database so it's easy to differentiate: put big red X on the opening layout or something. Tell all users to let you know if it's NOT there when they open the database. Go through *every* computer on your network and look for duplicate copies of the database. Zip them all except for the production copy.
December 2, 201015 yr Author Thanks, I have changed the server to windows server 2003 SP2, and still we loose data, each user connects via a separate 'opener' file - do you think this can cause an issue. Basically, this is what is happening, user A creates a new record closes it, opens it up on another occasion and enters some data - when they come back to view it the data has dissapeared - other data however still remains. The funny thing is they can reenter it and it stays, its completely random. Could there be something wrong with the fields themselves? or how I have set them up? Thanks again Sam
December 2, 201015 yr Author One more thing, I have just noticed that the data loss only occurs in the one table, which also has the most fields (456) if that means anything.
December 2, 201015 yr The number of fields should be irrelevant. Have you checked that the users are opening the correct file, and there is only one? Until you actively do something to identify the correct file, the issue remains open IMHO.
January 26, 201114 yr Newbies Hi all I'm having a similar problem to the above, and wonder if anyone can help? Our data is also dissapearing - We have a 50k of records, each record contains full company name and address details. In the last two months or so, address data that has been changed is reverting back to the old address. We have a datalog which logs any changes made to the data - it shows the original data, the change being made, but it doesn't show the data reverting back. When changing the data again (after it has reverted back to the original) the data log shows the same data being inputted as to what is stored, so for example: 26/1/2011 16:39:35 Country UK -» UK 26/1/2011 16:39:28 postcode CF10 5LE -» CF10 5LE 26/1/2011 16:39:19 county Cardiff -» Cardiff 26/1/2011 16:39:09 town Cardiff Bay -» Cardiff Bay So the data is still there and stored somewhere, but it isn't what is shown on the screen. I would appreciate any help anyone can give. Many thanks James
January 27, 201114 yr The issue could be that some script is running and touching the wrong records. Use any of the analysis tools (like BaseElements) to find out where some of those fields are used and then inspect those scripts and their flows to make sure they always run on their intended records. But don't ignore the advice about making sure that there are no copies of the files hosted somewhere else. And do the consistency check as Steven mentioned. Let us know what that produces. I've seen these symptoms in files that were accessed through OS sharing instead of going through the FM "open remote". Those files were thoroughly corrupted and had to be recreated from scratch.
Create an account or sign in to comment