It should be better now, it should attempt a reconnect the next time you query the database (e.g. open the symbol chooser) without having to quit KiCad.
By the way, there is a query cache, with the default cache lifetime being 10 seconds. So, you have to wait at least 10 seconds to see newly-added rows in a table. You can change this cache lifetime in the kicad_dbl file by adding a section like:
"cache": {
"max_age": 5 // 5 seconds cache lifetime
}
I am trying to get a database running with kicad as well and might be almost there. I have been through this thread and related links quite a bit, have installed linux versions of sqlite/odbc sw and the kicad-provided .sqlite and .kicad_dbl test files. With db-browser (and the similar sqlite-studio) I can open and edit the db, and I see how to pull my own db together via csv import from my existing component spreadsheet. I think I have a decent handle on the database side of things for the moment.
The .kicad_dbl file for mapping makes sense and I now want to add the db to kicad to see how it works, before building my personal database. I cannot seem to add this .kicad_dbl file to the Symbol Libraries Table in 6.0.10 as the file type is not recognized. I am guessing that I need to install the nightly version to test this out ā is that correct or is there a way to play with it in 6.0.10? I was going to wait for v7 before diving into db usage but now I really am itching to try this out and start building a proper database. thx.
yes, you have to install nightly (6.99), 6.10 doesnāt have āDatabaseā as Library format.
I got the sqlite database working with the nightly release and it works very well. Trying to decide on a schema I like but looking forward to being able to generate a custom bom from all the fields. I would like to add cost and availability info for each part from mouser and have been playing with their api and pulling part data with python. That has been easy enough, but now need to parse the response json to get the fields I want, and then use that to update the db. I just want to manually run an update program to refresh pricing/availability fields before generating a custom bom. I am thinking a separate mouser table keyed on their part number (and maybe digikey later). Has anyone been down this path?
You can of course do this if you want, but since cost and availability data is dynamic, my approach would not be to store it in the same database as part information (which tends to be more static).
If I were to do something like this, I would have a script that could pull the latest cost/availability data for a list of parts after exporting it from KiCad, rather than trying to pull the cost/availability data into KiCad via the database. With the latter approach, youāre inevitably going to have stale data in your KiCad design, which doesnāt seem that useful to me.
I see how they are two different functions. The part data changes relatively infrequently, and pricing/availability is a real-time update when a script is run, and yeah, using two different databases is logical. But if it is in the kicad part db it is really appealing to be able to define a custom bom that generates everything in one click ā something I have always had to do manually by tweaking a stinkinā spreadsheet. For a small shop sending a build off every couple of months there is no luxury of the systems a big place has. It ends up as: generate a bom ready for the build, then go to order only to find that some cap or whatever is not available, last-minute manual part substitutionā¦ I just see how I can finally have a parts db with some current availability info so I can adjust as the design progresses. Kicad is making it possible for a small shop to save a lot of time and I canāt be the only one salivating 
You could do this with a CI job if you store your projects in a git repository ā use kicad-cli to export the BOM, then run a post-processing script to attach pricing/availability info to the BOM (this could also issue warnings if parts are unavailable)
Iām a bit mixed on this but mostly agree with teletypeguy - its is very useful as a small shop to have the cost data in the database, even if it gets out of date.
That said, I think the volatility of part availability is to much - especially in current times, with part shortages all over, etc.
I also used the fact that part cost information was out of date as a driver to keep my database up to date. For example, Iād complete a design, and then upload the BOM to digikey or mouser, and it was fairly easy to see what part costs had changed. Iād then go back into the database and update those that needed it, or if it was a group/family of parts that were all priced the same, update them all.
Not perfect, but definitely nice to get a quick glimpse of what the cost drivers were in a design really quickly.
That said, a script that would update the database with that dynamic data from mouser or digkey would be the cats ass. Even cooler would be to have it pull from both so that you could upload each BOM and determine who had the majority of the parts and who was cheaper!!
I know, I knowā¦ scope creep.
Well, at risk of this being deemed off-topic, or spun into a new thread, here is my initial test of pulling data from mouser (inquire with them and they assign an apikey to you):
import requests
import json
partnumber = "512-FDN340P"
api_url = "https://api.mouser.com/api/v2/search/partnumber"
# key assigned by mouser:
api_key = "ac5(blahblah)955e"
url = api_url + '?apiKey=' + api_key
headers = { 'Content-Type': 'application/json' }
body = {
"SearchByPartRequest": {
"mouserPartNumber": partnumber,
"partSearchOptions": ""
}
}
try:
response = requests.post(url=url, headers=headers, data=json.dumps(body))
if (response.status_code == 200):
# >>>> still get here with error for bad key or bad body
partdat = response.json()
print(json.dumps(partdat,indent=3,sort_keys=True))
# >>>> need to parse here, update extenal db...
else:
# bad url (404) etc:
print('\tERROR - bad status code:', response.status_code)
except Exception as e:
# no internet or other problem:
print('\tERROR - post problem:',e)
@Antartica The goal of KiCad is to enable users to design circuit/boards, not contain metadata for BOM, component pricing, etc. which you can do with your remote database.
I havenāt tested this hook yet but it seems pretty straightforward, bravo in listening to your users and implementing it!
Says who? If thatās your use, thatās fine. My needs are a cohesive schematic and PCB design environment, and when I design a board, developing a BOM is a core part of that. The ability to develop a database that meets the users needs shouldnāt preclude one field over another - the user should decide what that database should include and having one ubiquitous database with all the part information I want to see make sense. If KiCad can punch out a custom BOM that happens to includes part cost, so be it. If thatās not necessary to your needs, donāt make that field in your database or donāt generate it via KiCad.
I almost commented earlier as I was afraid that the post might come off a little āwrongā. This is a case on where to draw the line but leave open the possibility of implementing other use cases. Development cycles are precious, especially in open source.
Says any decent engineer who knows that there are already various tools available for that (btw check out InvenTree which does what you ask) and doesnāt want their CAD tool interface and functions to be cluttered with the same information already present on those project/revision/BOM/component management tools. The database library connection enables the link with those tools, it does not mean KiCad dev team should bring all those features into the existing CAD interface 
I donāt think the kicad dev team is being brought in to the picture in any of these scenarios. It is just a discussion of what data to put in what database, as far as I can tell. KiCad is not going to add native lookup of component price and availability, but nothing stops people from using scripts (or other peopleās scripts) to dump that data into symbol fields if desired.
As @craftyjon inferred, Iām not advocating any native KiCad ability to look up cost data. My post was in reference to the script that @teletypeguy was developing. KiCad developing a BOM and pulling whatever fields are needed for that BOM from the parts database is a useful capability that could include part cost data. This is a fairly standard capability (altium, old orcad) that any ādecent engineerā should be familiar with.
That said, this has been a fruitful thread with a lot of fantastic results. Lets not pollute it further with our disagreement (if we even have any) and get back to the discussion at hand (KiCad database driven design). Lets agree to disagree and move on.
Sounds like @Antarctica may be in a similar workflow as me. I have maintained a master parts spreadsheet for years, adding parts as I need to, with primary vendor/vendorpartnum/pricing and same for a secondary vendor. A lot of manual work that I would update periodically as a new project comes together and I want board cost summarized in my bom (deleting cost columns for the assy house bom). Just did not have a good reason to improve on that workflow until now. Kicadās database interface will let me move it all to an sqlite db, and I can do more than just place intelligent symbols now ā I will be able to pull any of the db fields into a custom bom (have not got to that part yet, but sounds easy enough). I am not asking for any new kicad features, just enjoying the new features that v7 will give me as an old fart learning new tricks, grinning and saying thank you to all the awesome kicad devs!
Well, with a bit more python hacking I can pass a mouser part number and buy quantity and pull the available quantity and price at my buy quantity. Next up is poking that into an sqlite db. @eeintech ā thanks for the mouser lib. I peeked through it as I was trying things out, but as a bare-metal kinda programmer I wanted to dig into the details and learn a bit more python. Have written oodles of C since the 80s but only a year or so in python land, so it is a good chance to learn more.
I thought about separating the main parts db that kicad will use and have another for mouser, probably one for digikey (donāt use them too often) which get updated as desired and then use some sort of post-processing script as @craftyjon suggested. That may well be the clean way to go, but I think I will initially try including vendor availability and cost columns in the parts db, and just running a python program to pull current info and update as desired. Will only need to run it now and then, and then I can, from within kicad, generate a bom with cost info for me and one without it for the assy house. Thinking out loud on much of this, but it is an interesting project.
thx, gil
I have a question about database-sourced parts and DNI (do not install, aka DNPā¦) parts:
In my v6 library I only had atomic parts when absolutely needed and general parts (cap, resā¦) simply had a value assigned in the schematic when placed, and I would set value to DNI as needed. It was easy to find in the DNI parts in the bom and deal with them.
Now as I move to a database for v7, everything is intrinsically atomic (not that there is anything wrong with that) but what to do about DNI parts? I can assign say an 0402 cap whose value is pre-defined as DNI and place as needed, but that gets clunky to do for more than a few types of parts that may be DNI. Unsure how to deal with DNI parts with the database since value will be hard-coded.
I heard about an upcoming āassembly variantā mechanism in the works somewhere and wonder how that plays into things. Should there be a DNI field for each symbol ā something that is visible at bom-generation time? thx
KiCad 7 has a first-class DNP setting that may be used if desired
DNP parts are shown āgreyed outā in the schematic editor
For DNP parts I typically hide the Value field and create another field āDNPā that I show on the canvas:
Awesome! I see that now in 6.99. I have not used 6.99 yet except to figure out db stuff. Yes, that DNP property will be great. So just choose a feasible value part from the db (since all will be atomic), set the dnp property and hide value if desired.
Perfect. thanks Jon
