Author Topic: Central Database & More ?  (Read 982 times)

Johno

  • Full Member
  • ***
  • Posts: 191
    • View Profile
    • The Poker Leaderbaord
Central Database & More ?
« on: April 02, 2013, 09:20:52 PM »
Hi all,

It's been quite a while since i've been around these forums. Have moved on from running my poker league and have also moved on from running The Poker Leader board. But it is in good hands.

Now i'm just into web development it seems Poker Leagues are onto me.

I have a client looking to have me build their website for their poker league, and want it to integrate the leader boards automatically. Now I know I can do this with using The Poker Leader board.

The other thing he want is to have 2 separate computers running TD at different locations, and register players on the night as per normal. BUT then be able to sync from the web, a central database of players.

Is this possible? What is the method to do this?

Thank you in advance.
My League Website - Joomla Component for TD. Now available for Joomla 1.5, 1.7 & 2.5

Corey Cooper

  • Administrator
  • Hero Member
  • *****
  • Posts: 5380
    • View Profile
Re: Central Database & More ?
« Reply #1 on: April 04, 2013, 09:59:13 AM »
The software isn't designed to share its database, so no, that's not a supported feature.  But it can be done, with certain limitations.  There are others on these forums who do this on a regular basis.  For example, see this post: http://www.thetournamentdirector.net/forums/index.php?topic=3635.msg17467#msg17467

Johno

  • Full Member
  • ***
  • Posts: 191
    • View Profile
    • The Poker Leaderbaord
Re: Central Database & More ?
« Reply #2 on: April 07, 2013, 07:06:01 AM »
Hi Corey,

Thanks for the reply. That seems to be good for multiple PCs at the same location working over a network.

Here's the scenario. I'm sure others would be doing similar.

The client runs poker at 4 venues.

Venue A - Monday night (using laptop 1)

Venue B - Wednesday night (using laptop 1)

Venue C - Wednesday night (using laptop 2)

Venue D - Thursday night (using laptop 2)

Venue A & B are on one side of the state, and C & D are on the opposite.

The idea is that they simply want one central "Player List"

So if a player that regularly plays at Venue A is travelling and plays at Venue D, they can simply give their name to register and not have to give all the additional details the company may usually ask for.

The idea would be ok if at the end of each tournament Laptop 1 & Laptop 2 have to be "Synced" to somewhere central. Even if it was Dropbox for example.

Or can the players list be "Merged" then re-imported again in this way somehow?

I know there is a company that runs locally that started with your software many years ago but seems to have a custom system now (maybe a fork?) that has this "Sync" option there. So how much trouble would we be looking at to achieve this?

Can you think of any solution ?
My League Website - Joomla Component for TD. Now available for Joomla 1.5, 1.7 & 2.5

Corey Cooper

  • Administrator
  • Hero Member
  • *****
  • Posts: 5380
    • View Profile
Re: Central Database & More ?
« Reply #3 on: April 08, 2013, 02:37:19 PM »
A solution could be: Have a "central location" for the database.  Copy the database to the laptop before use each night.  After use each night, copy the database back to the central location.  Done.  A simple way of synchronizing.  The issue is you have two laptops running tournaments on Wed.  You can copy the database from the central server to each laptop before use on Wed, but after use copying the database back from the laptops to the central location presents a problem.  Any changes made to the database on the laptop that copies back to the central location *first* on Wed night will be lost when the second laptop copies its database back to the central location.

In reality, use on the laptops probably consists only of (a) adding new players and (b) changing existing players data.  It's unlikely a player would be deleted from the database on the laptop, or that a change to the same player record would occur on two laptops on the same night, since a player can't be at both locations at once.  This could make an actual sync operation simpler, but it's just a one-off in that it's specific to your situation and wouldn't likely work for many, or any, others.  A real sync option would have to be more general.

I'm curious, though.  How would you like to see a sync work?

For example, since your laptops are in different physical locations, how would they communicate?  Are we talking push a button and the software talks to the central site, perhaps over HTTP?  (That would require a server.)  Are the laptops on the same network and thus could share drivers?  Or would importing/exporting (more like backup/restore) the database and sending those files via email work?

dullgeek

  • Newbie
  • *
  • Posts: 24
    • View Profile
Re: Central Database & More ?
« Reply #4 on: April 10, 2013, 02:18:36 AM »
What if you had an option to re-read in the entire database before writing to it? That way, you'd incorporate any changes that some other side may have made before you write out something new.

Corey Cooper

  • Administrator
  • Hero Member
  • *****
  • Posts: 5380
    • View Profile
Re: Central Database & More ?
« Reply #5 on: April 10, 2013, 10:50:14 AM »
There is an option to do this in 3.2.  But it isn't quite as you described.

There's a hotkey assignment to reload the database.  But it doesn't "incorporate" changes in the database with what your running copy of the TD currently has in memory.  It simply reloads the database, losing anything in memory and overwriting it with what is on the disk.

This can still work, however, as long as those using the program know to reload the database before making any database changes, such as adding a new player, editing an existing player, deleting a player, or making changes to leagues or seasons.

In a registration situation, the most common thing is to add new players, and probably occasionally make changes to existing players.  It's pretty easy to be sure to reload before doing one of those.  In fact, it might be feasible to add a preference in the future to have the TD do this automatically before those operations.