Aurora 4x
Starfire => SA Questions => Topic started by: coldsteel on April 28, 2007, 01:20:25 AM
-
Steve, can SA be played over a LAN and have multiple players accessing their empires at the same time?
-
Steve, can SA be played over a LAN and have multiple players accessing their empires at the same time?
Theoretically yes, but Access doesn't handle multi-user very well so its possible you might get an occasional error if two players try to access the same database record at the same time.
Steve
-
will these errors over time cripple the .MDB file?
-
will these errors over time cripple the .MDB file?
No, if they happen it will prevent an update rather than causing corruption. There is also a remote possibility that two players could lock each other out of the same record and both have to Ctrl-Alt-Delete but even then, no update would take place. The best idea is to try it as I am going on theory here rather than practical experience.
Steve
-
will these errors over time cripple the .MDB file?
No, if they happen it will prevent an update rather than causing corruption. There is also a remote possibility that two players could lock each other out of the same record and both have to Ctrl-Alt-Delete but even then, no update would take place. The best idea is to try it as I am going on theory here rather than practical experience.
Steve
It is possible, but as Steve points out, at some point, a lockout will occur. Two players hopping into the same system?
One possible way around this, if Steve wants to do such work, would be to move from Access to the SQL Server desktop engine. It would require rewriting all of his database access code, and porbably a bit more. So I sort of doubt that it'd happen
-
I have played a game of Starfire where everyone used the same database from multiple sources. We had some problems with two people trying to do something at the same time, but it was fairly rare. We also only updated one month every 3 days. I do not think that Aurora will work as well if you wanted to try it as everything is done on a more real-time scenario.
Brian