Ahh Chris, of course! That’s how to do it for now – just add the alternate symbol from the actual symbol lib when needed. Sheesh, that is easy enough to do and no extra parts needed in the db (and they show in bom). Still a bom tidy-up but easy to spot (S1 was placed from orig-symbol-lib and S2 placed from the db):
BTW, for what do you use the m.2 socket, besides a micromod module? I have used that socket for a micromod, and also made a micromod to plug into it.
It will not be possible to implement alternate symbols until V8 at earliest (alternate footprints are somewhat easier)
In the meantime, you could maybe accomplish this through database trickery. Things like sql - How to split comma-separated values? - Stack Overflow might be building blocks for separating out the field into a view that presents individual rows per symbol (use the semicolon, ;, as the symbol separator)
You could also do this without the SQL trickery by populating a table using a script that parses a source table and splits rows with multiple symbols into individual rows with the other properties duplicated.
@teletypeguy When I created the non-database symbol I simply added all the same fields that a db symbol would normally have. When I generate the BOM there is no “tidy-up” step, everything looks like it came from the db (row in yellow in the image below is a non-database symbol, all other rows are from the db)
@craftyjon Thanks for the good suggestion. I tried this tonight and I don’t seem to be able to get it to work. I split the symbols into multiple records in the db, but when I actually try to place the symbol in the schematic, KiCad always uses the first symbol in the db for all parts with the same “key” in the kicad_dbl mapping. In the schematic picker, the “Symbol” field is showing the correct symbol name, but I can’t get it to actually place different symbols in the schematic. (I don’t know how things work internally and if this is expected or a bug.)
It will not be possible to implement alternate symbols until V8 at earliest (alternate footprints are somewhat easier)
Thanks for the heads up 
If it’s possible to fix the multiple record/different symbol issue I described above in V7, that could allow a workaround until this is implemented for real in V8 (or later).
That’s the issue – you need to use a unique key for each row, so your key now has to be something other than your internal part number (that’s the downside to this approach)
Yup, that fixes it (as a test, I just used the DB primary key “id” as the “key”).
In my case specifically, the SQLite db primary keys are being generated from my PLM system (not under my control), so I’d probably have to add an additional field in the PLM with some sort of unique “key” I maintain manually in order to make something like this work (probably not worth the effort). I’ll try giving the non-database approach a shot and see how that goes first. However, for folks who have more control over the DB generation, this could be a good workaround.
i like the idea, i’ll give it a try. i quite enjoj sql ju-jitsu.
I found that my unique primary key (PartNumID) only has to be unique within a table and can be duplicated in different tables. Normally there would never be a duplicate key in different tables as this would break the master number system, but this can be exploited for the alternate symbol use case.
For parts for which I had an alternate symbol, I just created an AltSymbol table, copied the parts to it that had a second symbol, and changed only the Symbol fields in the new AltSymbol table. The new table needs to get added to the .kicad_dbl files also. Works well:
And BOM has all fields the same except one:
That’s brilliant! i’ll try right away.
For people with autogenerated ‘internal codes’ i think that the same trick can be done using database ‘views’.
Hello Everyone,
I have tried documenting the steps to get this feature up and running. Do give it a try.
Github repo
i think that the repository is set as private…
My bad, I have made it public now.
Care to explain this a bit more @craftyjon ? As @eeintech showed changing “column” to “Capacitance” works. But were does that leave the “Value” column in the database which contains that “{Capcitance}” value? Not needed? What did you use it for?
BTW, this database support may be one of the least sexy changes in K7 but for me is one of the best changes! I can now trash my home grown part numbering system and migrate it here. Very much appreciate this feature.
I’m not sure I really understand your question – maybe if you can explain what you’re trying to do with the database configuration I can give pointers on how to do it?
The example (QA ?) database from the site shows a Value column and a Capacitance column (for the capacitor table). The value column has the string {Capacitance} for all rows. Is this column necessary? What does it do? As @eeintech pointed out, if the Kicad_dbl file is not changed (see his comment above) component values in the schematic show up that “{capacitance}” string as their value. I.e., something is not being resolved. Once the mapping to the Capacitor column is made, it seems to render the Value column useless… Am I getting this right ?
It’s a QA test database, not really an example for users (but people have been using it as one). For that column to be resolved, the a capacitance field would need to be mapped also.
Once the mapping to the Capacitor column is made, it seems to render the Value column useless…
One use would be if you wanted to remap the Value field on a single symbol to different database fields in different situations, and also maintain the source of the Value field as a separate field (for BOM export, maybe).
Yah, I get that - I suspect it serves as a starting point for many (does for me). Anyway thanks for clearing that up.
Doodlebugger also had some trouble with setting up a database:
It would be nice to have one or a few (for different database backends?) examples directly in KiCad. I don’t know where they would fit best, either in the Demo Projects, Templates or even in the Plugin and Content manager,
People fluent with databases and their setup would not need this, but I recon there are quite some KiCad users for who this is the first time ever they want to set up a database, and a working example is a great starting point and a boost in motivation to dive deeper.
Use of the database libraries feature requires some amount of knowledge of databases, there is no getting around that. We could expand the documentation but it’s really not intended that KiCad be someone’s introduction to “what is a SQL database”.
Let’s say I have a main table for my parts but I would like to gather the symbol fields from different database tables, would this be a feasible implementation:
"libraries": [
{
"name": "Resistors",
"table": "Resistors",
"key": "Part ID",
"symbols": "Symbols",
"footprints": "Footprints",
"fields": [
{
"table": "ManufacturerParts",
"key": "Part ID",
"column": "ManufacturerPartNumber",
"name": "MPN",
},
{
"table": "PartParameters",
"key": "Part ID",
"column": "Resistance",
"name": "Value",
}
],
"properties": {
"description": "Description",
}
}
]
That syntax won’t work, but you can accomplish this fairly easily using a SQL view. A view is a “virtual table” that can pull together columns from multiple tables.