Error code 510, when you look it up in help, means "related value is empty or unavailable".
I'd check your relationships to see if you have valid relationships for your current file and the current record.
that was my first thought - have had same issue in past - spent many hours checking/changing - than i ran SCRIPT DEBUGGER - it has no error on first SET FIELD which uses same relationship as other SET FIELDS - would that indicate relationship OK?
i put a different SET FIELD first - for some reason whatever SET FIELD is first it shows no error -
Then it sounds like your file or possibly an index in the file is corrupted, But I'd have to see your script to be more confident of that.
You might try recovering the file and then test the recovered copy to see if it has this same issue. If the recovered copy works (test it even if recover reports no problems found), you might try using advanced recover options to produce a file with rebuilt indexes to see if that works.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- 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).
The one exception that I make to my "don't use recovered files" rule is that I will use a file where the only change made by recover was to rebuild the indexes.
If you have FileMaker 11 or newer, you can use Advanced Recovery options to rebuild your file's indexes:
- With the file closed, select Recover from the File Menu.
- Select "Use advanced Options"
- Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".
- The recovered copy of the file will be identical to the original copy except that it has completely rebuilt indexes.
rebuilt indexes didnt work - does this mean all TABLES are or might be corrupt? - can/should i copy paste other TABLES ive updated with the backup that works?
Did you do a full on recover? What results did you get from that?
no full - i dont use FM for business yet - based on above recommendations didnt want to continue and have the possibility of future problems so deleted all TABLES not working - can/should i copy paste other TABLES ive updated after the one TABLE went bad -
Yet we haven't confirmed that there was an issue with file damage and Recover could have confirmed that as well as it produces a log you can examine to identify which parts of the system might be damaged so that you can selectively replace just those portions of the file.
If you copy and paste a table, you might bring the damage with the table.
If you run a recover and it reports damage with your file, you can then do this one table at a time, saving backup copies along the way and use recover to see if the newly added table introduced issues into the file.
i based my actions - "may behave differently" "does not detect all problems" "doesnt always fix" "never use a recovered copy" - im just a two person home office trying to make office work flow easier - ill never know what you do - i learn certain script formats and try to use them in different situtations - how would you know if there was a issue when it doesnt detect all issues - after what was said i feel better going back to a working copy even though i dont know all that i have changed from that date - i appreciate the feedback i get - some helps some i dont understand - being this recover is not a guaranteed ITS FIXED ill use the index and if it doesnt work wont use recover - dont feel i have the knowledge you do to decide what avenue to take based on recover findings -
Yes, but turn it around. If recover doesn't always detect a problem neither are you 100% sure that a normally funcitoning file is not damaged either. It's a relative risk percentages game.
Note these statements:
Recover almost always fixes all problems completely...
If you run a recover and it reports damage with your file, you can then do this one table at a time....
Odds are quite good that if recover found the problem in the first place, then you can continue to use recover to check each item as you bring it from the recovered copy into your backup. It's a matter of balancing the small chance of an issue with the known quantity of the amount of time/effort it'll take to rebuild all of those changes "from scratch". If the amount of effort to rebuild from scratch is small, then it makes sense to rebuild from scratch. If the amount of time/effort to rebuild is large, then it becomes more reasonable to carefully bring over parts of the recovered file one section at a time with frequent tests and back ups.