Page 1 of 2

Auto-import & Move Process Files To on Ongame

PostPosted: Mon May 19, 2008 1:30 am
by fievel
If I use auto-import having Move Processed Files To checked on Ongame PT3 (build 2) deletes the db file from Resources\Databases folder of Ongame client software. I was surprised by this and consider this as a serious bug. The database files were actually copied to PT3\Processed folder, but it does not make any sense to delete the original db file. I did the import when my Ongame client was not running so I don't know what would happen to it upon the db deletion, but my Pahud which was still running after my session reported an error when it failed to find the db file. PT2 doesn't have the option to move processed files, so I have this will be fixed as soon as possible.

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Mon May 19, 2008 5:14 am
by WhiteRider
I'm not familiar with the OnGame DB specifically, but in PT2 other sites that use DBs (like prima) don't move the DB in "move processed files to" but do have an option to empty the hands DB. I don't know whether this is possible with OnGame, but if not then the DB will need to be moved or PT3 will have to read the whole DB again and will take a long time as the number of old hands builds up. I would guess that while OnGame is running it will have the DB open and would prevent it from being moved..
Josh will have to give a more detailed answer when he has time..

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Mon May 19, 2008 5:49 pm
by Josh
The OnGame client will (or at least, should) re-create the db file if it's missing, so having PT3 move it will cause no problems.

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Tue May 20, 2008 1:10 am
by fievel
PT2 behavior make more sense to me. There is no need to move the db file. I vote for it to be fixed.

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 1:21 am
by Josh
"Fixing" this problem involves permanently deleting the information inside the db file. PT3's method results in the data being archived, and not lost.

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 1:52 am
by fievel
I meant make it like it was in PT2:
1) "Reset DB's" button for deleting the data from the db files
2) No "Move Processed Files To" which is totally unnecessary for Ongame imo and which made me think that I lost my db when I saw that there was no db file where it was supposed to be.
Or can you explain what does it mean "archived"? And when does this archiving process take place? If it moves/deletes db files during my session, won't it interfere with Ongame client software?

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 10:48 am
by kraada
If you move or delete the db file, Ongame automatically recreates a new one, even if it happens while you're playing.

So wouldn't you prefer to have the version with old hands moved somewhere else (so you still have it) when a new version is created, rather than actually deleting the data from the file and not having it at all?

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 11:55 am
by fievel
In PT2 if I wanted to keep my db file I backed it up manually before clearing it.
I'm not sure that deleting db file and letting Ongame client recreate it is a good thing if it happens on every hand import, especially when multitabling. Wouldn't it be a performance issue?

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 12:02 pm
by WhiteRider
PT3 doesn't delete the DB file, it moves it. And it only does this when you stop auto import.
I doubt this would be a negative performance issue, if anything it would improve it because it would be using a smaller DB.

Re: Auto-import & Move Process Files To on Ongame

PostPosted: Fri May 23, 2008 12:10 pm
by fievel
WhiteRider wrote:PT3 doesn't delete the DB file, it moves it.

I know, but moving = copying, then deleting.
WhiteRider wrote:And it only does this when you stop auto import.
I doubt this would be a negative performance issue, if anything it would improve it because it would be using a smaller DB.

Thank you, that's exactly what I needed to know.