Inventory does not work.

[GoogleCodeExporter]

Hi,

I just found a very (very, very) annoying bug in ARDB 3.1.0. Okay, maybe 
I'm exaggerating a bit because I just realised the bug has messed up my 
ARDB inventory containing all of my 10000:s of cards which means I may have 
to redo it all. But anyway, as many other problems with ARDB this is 
related to entering new cards when having selected a specific expansion.

Previously, there was a bug/dysfunction in that whenever a specific 
expansion was chosen and new cards entered into the inventory, these new 
cards would be "transferred" to the first expansion featuring those cards 
rather than staying in the expansion where they were entered, and added to 
the total amount there. This made it impossible to record how many cards in 
the inventory were from which expansion, but that's perhaps a minor 
problem.

Now however, when selecting a specific expansion and entering cards there 
(which is still useful when entering many new cards which are all from the 
same expansion, as it makes finding the cards' entries faster), the amount 
entered is no longer added to the previous number of those cards; rather, 
the previous number of those cards is -replaced- by the amount entered for 
the specific expansion!

Needless to say, this is a rather severe bug for anyone who uses ARDB for 
inventory tracking, as it actually destroys the inventory when entering new 
cards. Which is what happened to me in this case.

Original issue reported on code.google.com by graham.r...@gmail.com on 21 Apr 2010 at 7:59

[GoogleCodeExporter]

Do you think we should implement some sort of back up mechanism for the 
database so
that in any situation the db would be backed up.

In initial state we can ask user with a message box whether he wants back up 
feature,
then create a backup/ directory, copy the current db, and whenever another 
backup is
required, take the diff, save it and that way you don't have only the current 
one but
also couple previous database states as well.

Original comment by gokturk....@gmail.com on 21 Apr 2010 at 8:16

• Added labels: OpSys-All, Priority-Critical, Type-Defect

[GoogleCodeExporter]

I think we need something for the inventory.  The data is to valuable to be 
left 
hanging around in the database.

We also need a better UI that allow user to more easily add cards for a 
specific set.

Original comment by graham.r...@gmail.com on 21 Apr 2010 at 8:26

[GoogleCodeExporter]

A quick question, how do we save the inventory? Inside the database or in a 
simple file?

Original comment by gokturk....@gmail.com on 21 Apr 2010 at 8:41

[GoogleCodeExporter]

A xml file right now.

Original comment by graham.r...@gmail.com on 21 Apr 2010 at 8:44

[GoogleCodeExporter]

Do you think it's worth saving it into a database? I'm not very well familiar 
with
libsqlite but i can work on backup implementation. What do you think?

Original comment by gokturk....@gmail.com on 21 Apr 2010 at 9:44

[GoogleCodeExporter]

Probably a good idea to make a copy of the database table each time it starts 
up.

g.

Original comment by graham.r...@gmail.com on 21 Apr 2010 at 11:03

[GoogleCodeExporter]

That should be make a copy of the inventory table each time ardb starts up.

g.

Original comment by graham.r...@gmail.com on 21 Apr 2010 at 11:05

[GoogleCodeExporter]

Is anyone actively working on backing up the database?

If not how about something as simple as making a copy of cards.db at program 
start up (before the database is read)? Allow the user to specify a maximum 
amount of space to use for backups and just keep as many cards.db backups as 
possible, named by date and time? This gives an advantage of being able to 
restore the whole database even in the event of filesystem corruption.

For now just keep the backup copies and allow the user to manually replace 
them. In the future add an interface to load a backup db instead of the current 
one? I'm just picturing a list of backups available. If the database is so 
corrupt it cant load the user could be informed and presented a list of 
database backups to load.

I'm imagining a preferences option with a tick box for keep backups (which 
should be the default IMHO) and a text box (or slider) to pick a maximum number 
of MB of Databases.

I have my cards inventoried as well btw, hence why I care :)

As an aside the backups could be compressed which reduces the db size from 
about 5MB to about 900K using gzip.

Original comment by JFHarden@gmail.com on 29 Jul 2010 at 8:27

[GoogleCodeExporter]

Personally, no. I still wanna work on unit testing and automake-autoconf stuff 
first. I had couple ideas for backing up the database but have no time for it.

Original comment by gokturk....@gmail.com on 29 Jul 2010 at 11:09

[GoogleCodeExporter]

Just a note about this bug.  It was a small error in the way information was 
written to the database so now the error should be fixed.  I think that the 
database backup is more a feature request than a bug anymore and should be 
designated as such. 

However, I do think its a good idea to always backup a database. 

Rob Woodruff

Original comment by Woodruffr1973@gmail.com on 30 Jul 2010 at 4:39

[GoogleCodeExporter]

JFHarden, Just another less vague comment.
I like the idea of what your talking about with the backup database.
It sounds nice.  And if and when graham does another build I would like for you 
to see the fix I made to the inventory function.  Any changes you would 
recommend I will look at.  I will hack away at the source and see if I can get 
it to do the backup your talking about.  I am also playing around with having 
DRAFT text added to certain cards.

Rob

Original comment by Woodruffr1973@gmail.com on 1 Aug 2010 at 4:06

[GoogleCodeExporter]

Revision 243 (https://code.google.com/p/ardb/source/detail?r=243) claims to 
solve this issue. I'll close this bug and file a separate bug for the backup 
mechanism.

Original comment by gokturk....@gmail.com on 21 Jan 2013 at 3:16

• Changed state: Fixed