The MeAnd23W_Shares table holds 23andMe sharing/dataset records — each row pairs a profile ID (psid) and a GUID with a display name and a source label. It shares the same column layout as MeAnd23W_Profiles, but it is the variant that the client actually references in its chromosome-segment queries.
MeAnd23W_Shares rows are joined against MeAnd23W_FIANew to build chromosome/segment output. 23andMe no longer offers the FIA chromosome data those queries rely on, so this table is effectively legacy and is not populated by the current gather flow.| Column | Type | Description |
|---|---|---|
| Id | int (PK) | Auto-incrementing primary key |
| loginUsername | string | The DNAGedcom username under which this row was stored |
| psid | string | The 23andMe profile ID |
| guid | string | GUID identifying the shared record |
| name | string | Display name for the record |
| source | string | Source label for the record |
| created_date | string | Date the row was created |
| sync | string | Sync status flag (set to “0” when a new row is inserted) |
MeAnd23W_Shares and MeAnd23W_Profiles carry identical columns, and the code does not spell out their intended purposes in plain terms, so any distinction is inferred from how they are handled:
psid + guid (and has a database index on those two columns), and it is the table joined into the legacy chromosome/FIA segment queries — consistent with per-profile sharing/dataset records.guid alone — one row per unique profile GUID across the database — consistent with a list of distinct 23andMe profiles available under the account.Beyond that difference in keys and usage, the code does not make the conceptual split explicit, and neither table is populated by the current gather flow.