At the end of the rope

[awarren]

Hello

I have a G4 running os 10.2 and file maker 5.5 server...we had an outside vendor create the filemaker database that tracks student progress...to tell the truth it runs great with very little admin work needed....In each class room i have an iMac running os 9.2. and the teachers log into the file maker with password...at least once a month a teacher will log in and create a new record and enter info about the student...exit and when they log in again the record is no where to be found....the vendor has blamed every thing under the sun... switches to old replaced the 3com with cisco...replaced the cat5 running from the server to the switch...its not the same person and same machine...just ramdom....any idears..... [email protected]

[-Queue-]

This usually happens when a user is entering data in Find Mode instead of Browse Mode, often after clicking 'Find' or its equivalent and forgetting about it, then trying to create a new record. It happens more often than you might think and I would hope that was the first troubleshooting question the designer asked.

[CobaltSky]

Hi,

If users are able to (seemingly) enter data into a new record (in browse mode), then the record must exist at that time. That would suggest that something is occurring which results in the subsequent deletion of the record. Or does the record exist, but simply not have the data they entered in it (in which case I would suspect that the network connection was dropped before the data was committed, as occurs at record exit).

To test this, I suggest that you look at contiguity of serial numbers (or if there are no serials, take a look at the results of the Status(CurrtentRecordID) number sequence). If there are gaps, that confirms that the records are created on the server and later deleted. If there are no gaps then look for blank/empty records (to see if its a problem with the commit stage).

If you have discontiguous records then 'inadvertent' deletion is likely to be the nature of the problem - and there are several things to look for;

1. Operator error - do the teachers log in with privileges that include record deletion? If so I suggest that that be changed and that they merely flag records for deletion (and that these be archived to a separate file in batches before being deleted from the file).

2. Scripting anomalies - is there a rogue script step eg in the sequence by which a staff member may exit from their login session - that might account for deletion of a record or records.

3. Duplicate File errors - if there is more than one copy of one or more of the files (with the same name) on the server or on any of the other volumes/drives that are accessible on the network, it is possible that on occasions, the wrong copy of one or more of the files is opened. When the correct copy is subsequently opened, naturally the data that was entered in the 'other' copy is nowhere to be found.

4. Cascading deletion - look for relationships that have the option to 'when deleting a record also delete related records' enabled. This option can soimetimes result in some unexpected outcomes where a legitimate record deletion is accompanied by unintended automatic deletions in the same or another file.

Of the thirty-seven things that could be causing the problem you have encountered, the above are four of the more likely causes. My suggestion would be to check them out thoroughly first, before starting on a longer list of the various more obscure anomalies (which include the gamut of hacking, corruption, network loops etc).

[CobaltSky]

Hi Queue,

Fair comment, and worth raising, but bear in mind that if that were the case the users should generally be experiencing error messages either:

A. the first time they press return or enter or do anything else which will execute the find (whereupon they will most likely be confronted with a 'no records match this request' dialog), or

B. after entering a few 'new records' (requests) in find mode, FileMaker automatically prompts to check that the user is not in find mode by mistake.

Moreover in find mode, auto entry options, lookups, relationships and calcs don't work - so in most solutions, even the most novice users realise that something is amiss before they get far.

In my experience mistakes of this kind tend to be localised to particular individuals whose grasp of basic software concepts is especially threadbare - whereas awarren has said there seems to be no pattern to this occurrence. For all these reasons it would surprise me if mode-mistakes were responsible for what it seems is a widespread/recurring/random phenomenon. But then again, perhaps there is something about the design of this particular solution that makes it possible...