Why not?
This is what I see in the place window:
And then in eeschema:
So I understand the ${Capacitance} value placeholder in your test database needs to be updated or is there some automatic update missing on my side?
Because the symbol editor does not have autoplace fields, which is basically required to use database libs where you have fields added that werenāt present in the source symbol, and because KiCad is not a database editor, so there is no point in opening the (read-only) database lib in an editor. You should only be opening the source library (Device in this case) in an editor if you wanted to modify the symbol graphics or pins.
There is no field mapping for Capacitance in the kicad_dbl file so this reference is not resolved in the Value field. You could add one if you wanted to.
I see better how it works now thanks. Should database library be added to the list of libraries in the symbol editor left panel? What is the need for this?
Ok I think I got it, in your test file Iāve replaced:
{
"column": "Value",
"name": "Value",
"visible_on_add": true,
"visible_in_chooser": true
},
with
{
"column": "Capacitance",
"name": "Value",
"visible_on_add": true,
"visible_in_chooser": true
},
And it works now:
The āValueā column is optional I guess in the database if mapped to other field?
Nicely done, this is looking promising! 
No, Iām probably going to remove it, just havenāt gotten around to it.
The way you changed it is fine, and it would also work to add another hidden field āCapacitanceā and reference that from the Value field.
1 Like
Iām curious if anybody using DB libs has parts in their database where the same part can have multiple schematic symbols (check out the āExample use caseā section of the issue I filed here for more details Allow picking from multiple schematic symbols for a single database part (#13584) Ā· Issues Ā· KiCad / KiCad Source Code / kicad Ā· GitLab).
Anybody else run into this and found a good way to work around it with the existing implementation of DB libs in the RC1? Iām wondering if there are better ways to handle this other than creating multiple parts in the database, where the only difference between the parts is the schematic symbol.
2 Likes
Yes i have several FPGA and high pin count microprocessors for wich we have different Symbols for the same internal code (OrCAD/PADS).
Unfortunately up to now i think it is not possible to do so with KiCad, i opened a feature request some time ago:
but since the audience of the dblibs is at the moment a very limited pool i think that the requests will not gather sufficient momentum.
there is already in place a mechanism for the selection of different footprints, so maybe in the future will be possible to extend it to the db symbols and footprints; iāve seen that Craftyjon has assigned the task but i think that at the moment all developers are focused on the release of V7.
One way to work around this is having in place in the db a mechanism to manage internal code equivalence.
In my case, sadly, I donāt think that for me can work out, since our internal code is by definition āatomicā and we have a very poor way to manage automatically code equivalence in our db management sw
(we add manually to a ānotesā field the equivalence on both codes to ālinkā the latter, when more than 2 codes are equivalent things goes wrong very fast).
Yeah, I am pondering just making alternate part numbers for alternate symbols, something like 1234567 and alternate 1234567-1 or something. Then they will be easy to spot on the bom for a pre-assembly tidy-up, but it is a bit clunky. They will also be easy to identify and remove when there is proper method to do it. Having an alternate symbol selection is the one big missing feature in the new database implementation, but Iām not complaining as the db is awesome! There are quite a few use cases where it makes the schematic much cleaner to use one symbol vs another for the same part.
if your primary key is a string (not auto-generated) you can do that, the down side is that you must keep the two codes up to date manually in case of modifications.
Yeah, my key is a string, so easy enough, and I have less than a dozen parts for which I have defined alternate symbols, so it is not a major effort, just a bit clunky. But hey, still not complaining about the new database functionality :):)
Thanks, I missed that one when I was searching for existing issuesā¦ I gave it a thumbs up to boost it.
Yeah, I didnāt realize how important this feature is until I started actually trying to use db libs on a new design.
For now, I think Iām just going to create some duplicate non-database symbols in a different library for the parts which require custom schematic symbols (I donāt really want to create a bunch of duplicate parts in my PLM system if I can avoid it). If the ability to add multiple symbols gets added to KiCad in the future, at that point Iāll just migrate those parts over to the db lib.
Thanks for the feedback! glad to know Iām not alone in this one 
1 Like
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.
1 Like
@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:
3 Likes
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
7 Likes
i think that the repository is set as privateā¦