Hi is there any viewer or anything i can do so when i check out the table it would show me updated numbers.. so for example if i have players position send to sql every 2 seconds it would show me the number change right in the table without refreshing the table. sql lite works but i have to somehow refresh it every time.. and i don t want that..

Or if there isn t any viewer can I make my own and somebody could point me out where to start??

I would personally avoid reading/writing to SQL unless I am saving/loading. Accessing every 2 seconds for a lot of players would be VERY expensive.

(05-16-2014 05:42 PM)aceio76 Wrote:  

(05-16-2014 01:27 PM)Rubeus Wrote:  I would personally avoid reading/writing to SQL unless I am saving/loading. Accessing every 2 seconds for a lot of players would be VERY expensive.

I have to say this will vary, but I mostly do not agree with this statement because enterprise-level SQL servers are built to handle dozens of requests per second. Again, I will caveat that it will depend on db design and application design, but in general, SQL (MS SQL, MySQL, other enterprise-grade SQL) can handle even over a thousand transactions per second. The question then becomes do you want to offload data to the db that often or not, do you want the latency that the DB introduces when getting/setting data vs having it in cached locally, and the list goes on.

I would find flushing to disk at x interval and on exit as well as only reading when loading would be a more economical solution. This way, the server would be reading the player positions from memory(x ns lookup time) vs from disk(4-15ms). Keep in mind that requesting a read will tie up the response by that amount of time(not to mention the time it takes to actually search the DB). If someone is connected with 40ms latency, adding 7ms(average seek time) is nearly a 20% increase.
Granted, if One has an enterprise array like and EMC or 3par or Oracle as Aceio is talking about, they can handle a crapton of requests before they start to get bogged down, but there is still going to be the seek time of the hard drives(4-15ms). Not to mention, this is expensive monitarily as well.

TL;DR Reading and writing realtime as a method of getting information from the server for gameplay is usually a bad idea. Reading once to get the required information is pretty standard, but it's often better to try to keep the information that is actively being accessed in memory, with the occassional write to make sure information isn't lost during an unexpected event.

thnak you guys for your responses.
so in other words if i have server window up and running i should just make a place to display it right in the window rather then sending it to the sql.db..

If i understood you correctly.

and you said that unless it saving loading.. so what are you sayng it is better do saving loading with sql rather then using file system in esenthel?? cause you can do saving and loading with server using files.. which way would you say is better??

It depends on who you ask. For instance, I would choose file IO almost 100% of the time over relational database. Obviously, there are cases where it makes much more sense to save data in a database but for serializing classes and basic data structures for a game, I'd rather not complicate it with database connections and SQL statements.

Keep in mind that I'm preaching against writing disk often in general: everything said I agree with. But writing to a DB or a file even as spaced out as every 30 seconds is pretty extreme, given the constraints. I prefer an event based I/O system where things are read or written only if certain conditions are fulfilled to keep the disk operations to a minimum. Aceio, you are correct, but when I was referring to the seek time, that's the basic time it takes the head to move to the correct position on the platter regardless of what program is calling for the data. Processing where the data is on the platter is extremely quick in SQL, and adds only a negligable amount of time, especially with caching and such.
For outputting information specifically for reading debug information, I would personally use the LogConsole(); in Init() and Log(S + "ObjType InfoType: " + infoToShow + "\n" ); in an update(maybe with a time check to prevent excessive spam). (I use that format so when I want to disable or change it, I know to look for ObjType in ObjType.cpp and don't have to hunt for it.)

thank you guys for clearing out some things for me.

As usual, Aceio provides a detailed and accurate answer