"Error 3201 was generated by DAO.Recordset
You cannot add or change a record because a related record is required in table 'StellarType'."
Due to repeated apprearances, I have narrowed this down to the 'DA5-' type white dwarf stars. 'DA6-' is okay, but I can't speak to any other 'DA' white dwarves.
Finally found it !!! Yeah!
It was related to white dwarfs. There is a 20% chance during system generation that a companion star is of the same size and spectral type as the primary, but with an equal or lower spectral number. So if the primary is a G5-V, there is a 20% chance the second star will be from G5-V to G9-V. In the code, there is a small routine that looks for a suitable star based on the letter code, size and spectral number. So in the case above, it would be given "G", size V and a random number between 5 and 9.
This works fine for every star type except white dwarfs because the spectral letter doesn't change. However, for white dwarfs there are sub-types of DA, DO, DB, etc. but a single range of 0-9 spectral numbers covers all of them. So you get DA5-VII and DA6-VII but then DQ7-VII, DC8-VII and DC9-VII. So when the primary was for example a DA5-VII, this routine was given DA, VII and a random number from 5-9. If the random number was 5 or 6 then it worked fine but for 7-9 it couldn't find a matching star type so it returned -1. I had included a error catcher for -1 on the primary but not for this particular sub-routine so that very occasional -1 was getting through and causing the problem.
I have solved the problem by removing the sub-types so all white dwarfs are simply D instead of DA, DQ, etc. There were two other situations that may also have caused the problem. The L type stars only went up to spectral number 8 and the T type stars only reached spectral number 6. I have added four new star types to take both up to 9.
The error was rare because white dwarfs account for only 5% of star types and even when they were the primary, the matching star routine happened in only 20% of those cases. Even then, it had to be one of the non-matching spectral letter types so the overall chance was below 1%. I had to generate 160 systems to get the error to occur. The L and T types between them account for 6% of stars but the error was less likely to occur for them because it was only 10% and 30% of spectral numbers respectively that were affected (in the 1.2% of cases where an error was even possible).
The only drawback to this is that it is a database fix so the error won't be corrected until v3.2. If you upgrade to an eventual v3.2, you will also lose saved games. I will be putting out a v3.11 soon that won't affect saved games but this fix won't be in it. However, if anyone wants to try and correct their own database and they know the password, they should open the StellarType table and change all ten of the DA, DQ, etc. codes in the SpectralClass field to just D.
If you are feeling more adventurous, you could also copy the L8-VII row and change the new row to an L9-VII row by changing the SpectralNumber field from 8 to 9. Similarly, you can copy the T6-VII row three times and change the new rows to T7-VII through T9-VII.
Copying a row is done via highlighting the row and using Edit -> Copy and then Edit - Paste Append. This will add the row to the bottom of the table. Don't worry about changing any other fields to make these new stars any different as they won't get picked up by the standard star selection routine anyway. Its just to avoid the error.
If you try this - back up first!!
Steve
