Author Topic: DBLib table browser memo  (Read 1636 times)

0 Members and 1 Guest are viewing this topic.

Offline PlainNameTopic starter

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
DBLib table browser memo
« on: May 04, 2021, 08:15:01 pm »
I am using sqlite3 for a component database, via the ODBC driver from:

http://www.ch-werner.de/sqliteodbc/sqliteodbc.exe

Works very well, except that it doesn't quite fix the issue of Altium holding the database open in exclusive mode. If I add a component via an external DB browser (actually DB Browser) with Altium open, a database refresh will see the new component, but placing it doesn't include the right data. Typically it will end up as whatever the schematic symbol is setup for (i.e. the default footprint for that, the comment, etc. Close Altium, flush the database, restart Altium and all is fine. But it's a dent in the old workflow.

So, I am testing the Devart sqlite ODBC driver. This costs actual money (or will if I buy it) but seems to work well. I can add a component and use it straight away in Altium after hitting refresh, and it's the proper component with all fields as they should be.

But... one snag: in the DBLib editor, in the table browser view, every field is either "(MEMO)" or "(Memo)". If I right click a part, the context menu offers to open symbol or footprint whatever, and that whatever is the right name for that part. But the table browser shows (Memo).

Anyone got a clue what might be causing this? I don't tend to use the table browser, but sometime I might find I need to, and generally things being not as expected indicate some fault or failure which may not be readily apparent.

FWIW the connection string (most of which I don't think I need because it's just replicating what the driver is set to) is:

DRIVER=Devart ODBC Driver for SQLite;ODBC Behavior=3;Journal Mode=WAL;Locking Mode=Normal;Synchronous=Normal;String Types=Ansi;Database=<path to db>
 

Offline Pseudobyte

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: us
  • Embedded Systems Engineer / PCB Designer
Re: DBLib table browser memo
« Reply #1 on: May 07, 2021, 02:17:07 pm »
If you can get around in sqlite you should just run a local postgresql or mysql server, you won't run into the issue of exclusive access. SQLite isn't designed to be accessed by more than one thing at a time.
“They Don’t Think It Be Like It Is, But It Do”
 

Offline PlainNameTopic starter

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: DBLib table browser memo
« Reply #2 on: May 07, 2021, 04:02:12 pm »
I have an aversion to 'server' anything locally, partly because they are running all the time and partly because they are shared resources. A big factor is also backups - you can't just take an image of the drive but have to either shut down the server or tell it to dump its data.
 

Offline Pseudobyte

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: us
  • Embedded Systems Engineer / PCB Designer
Re: DBLib table browser memo
« Reply #3 on: May 10, 2021, 03:33:45 pm »
That makes sense I suppose. When posgresql is idling on my pc it uses <30MB of memory and an intangible amount of my CPU, I do have 16 cores though. Dumping the database to a file is simple to do and easy to automate.
“They Don’t Think It Be Like It Is, But It Do”
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf