Notices

I'm assisting in an international move and the person moving needs an itemized list of *everything* being shipped (for shipping insurance and customs purposes). We want to use the barcode reader on my phone to make a database of everything with a barcode.

So the question becomes what is the "best" database to store a large number of items. We're talking over 1000 dvds + a large graphic novel collection, about 200 console games, etc.

Any pointers would be appreciated!

I use Postgresql for work and it's great no matter what you throw at it.

For the size of your database I believe that Mysql or even Sqlite can do the job.

However I can't help you on installing any of these babies on your N900. Not sure if there are native ARM ports. I believe that it can be done through easydeb.

Good luck!

sqlite3 is preinstalled on the n900.

Is there a plugin to write to a sqlite3 database from mbarcode?

No, but it would be easy enough to code up (I would offer to do it for you now, but I'm waiting for my fixed N900 to come back to me by post).

In the mBarcode thread I posted a simple example of a Python plugin that wrote to a text file for someone, but I'm not quite sure about the status of the Python wrapper plugin in the latest version of mBarcode as the api has changed and I've not had a chance to get it working again yet.

Certainly a C++ plugin would be easy enough to write, just take a look at the existing plugins and feel free to ask.

I'm not a programmer, but I would be willing to make a donation up front if someone (you or someone else) could get this working for me.

I need something that will let me scan movies (dvds/bluerays), books (including graphic novels), console games, and CDs, and grab their basic information (barcode, name, format, year, etc.) and new price on Amazon. It would have to push the information to either a spreadsheet (a csv-style text file would also work as long as it would be importable to something like Open Office as a spreadsheet) or database program.

An interface that would facilitate "bulk" scanning (ie: only having to press a single button to go on to the 'next' item) would be best. I tried several apps under Nitdroid but no barcode scanner seems to work with the camera (an unexpected wrinkle).

If mbarcode's plugin framework doesn't work, that would be another unexpected wrinkle.

Get a good camera (DSLR?) and make pictures? Will probably be faster, and it will capture both the item and the barcode

I don't want to be argumentitive, but I don't see how providing photographs of 1000 dvds (etc) will do in shipping items overseas in a cargo container.

I'm assisting someone in building a paper list of their personal inventory of items. This paper list needs to include basic details about the items (name of item, "edition" or "version" if there is one, media form, etc), and the NEW price of each item, for replacement value.

We *are* photographing electronics and furniture. But I need something that can read bar codes, scrape information about the bar code online, and then write the item info and price to a database or spreadsheet.

I may be misunderstanding what you mean when you say to photograph these items?

Ok, so there is unfortunately no working price and description scraping plugin for mBarcode yet (there was sometime in one of the very old versions of mBarcode, but it would sometimes segfault, which is not ideal, so I removed it) I will get back working on this once my N900 comes back to me, but I fear that will be too late for you.

Now don't get me wrong here, mBarcode works well (IMHO), but I'm not sure I'd necessarily want to use it to import many hundreds of items.

For that purpose I was thinking (as I will need to import my many books and fewer DVDs) of either writing a stand alone import app, which just continually scans as quickly as possible (and beeps to give you an indication that a barcode has been matched - this is important) and saves the EAN/ISBN numbers to a database/flat text file that can later be imported and populated (lookups, get item data, prices, etc.)

Before I had mBarcode working I used the zbar command line app + webcam on my Windows box to cat the ISBN barcodes it detected into a text file that I could later import, but even this setup (move book into position, wait for bleep) was awkward and using a barcode wand would make much more sense from a usability point of view (wands are very quick, even quicker than my desktop PC running the image analysis software, and most importantly they don't need good lighting and can be moved around very easily, esp if they are wireless).

So to summarise, I'd get a barcode wand if you have lots of stuff to import; if you don't want to invest, then I'd just use mBarcode to send the scanned ISBN numbers automatically into a text file that you can later parse and get descriptions/prices for.

There's a Python plugin on this page that will add scanned barcodes to a text file: http://talk.maemo.org/showthread.php...arcode&page=70

Remember you'll need to grab an older version of mBarcode (there's one on that page actually, which ought to work), which uses the old plugin API with which the Python plugin works. As I said before, once I get my N900 back I'll fix this issue.

Sounds like a quite fast solution but you should bear in mind that it is possible (especially with ISBN) that numbers are assigned to more than one product. Regarding ISBN many publishers re-use numbers after some time so you could run into the problem that you scanned the numbers correctly but later retain the wrong information for that number.

A better solution could be to additionally save some self generated information together with that scanned number to be able to verify the data later or to retrieve the data in real time and to verify the received data immediately. That would probably take more time but you'd be sure to have correct information. I bet you are not able to check 1000 items from memory after having them scanned in one go! Especially insurances are extremely unhumorous when detecting wrongly declared items! In worst case you'd lose complete insurance because of one wrong entry!

Another argument against scanning before retrieving is the possibility that some items might not be available via amazon or some other database. Then you'd see just some long numbers without any other information and would have to dig the whole bunch for that special item. NO FUN

Regarding suitability of sqlite for that size of database: no problem at all. You are talking about a database with some thousands of entries, likely less than 10.000 entries. You could start thinking of some more mature database when handling some millions of entries! A spreadsheet instead would be no good for that purpose as they are meant for handling less data in one table (even if they offer the ability to store some 10k of rows in one table).