   Database question: Don’t want to install on client computer; how to use?
  I have a question regarding databases and how one should connect to one from a game. The querying and such I pretty much understand (thanks to Developer’s Guide to Multiplayer Games -- pfft no link in GameDev.net's books aparently) (which uses MySQL). What is confusing me is how to connect to the database.  You see I want the user to be oblivious that I’m using a database, i.e. so they don’t have to run a daemon before playing game or the like. Now in a client/server setup I’d say it’s ok for the server to have to have a database properly setup for the game server to function, but I cannot see such a requirement flying for the game client. So my question(s):Can I access a local database without running a database server (i.e. daemon) ?I am not picky on what database engine to use, I've some code and understanding with MySQL so I was going to use that, if I can.I should only need a pointer in the proper direction, but I always value input I’m sorry if this is a stupid RTFM type question.. Everything so far I have read has said you must have the database (MySQL in this case) installed on the system before running the programs. I’m Pretty certain there is someway around that. (Clipmate for instance uses a MySQL database and the user does not have to have a properly installed database to use it). Anyway If it's a RTFM, which manual? For arguments sake lets say this is for a rather large single player RPG with lots and lots of ITEMS, NPCS, etc. that should all be stored in a local database. Oh and speed is not an issue.Any help/pointers appreciated /waveFeral[edited by - FeralOfFiretop on August 1, 2003 2:38:12 AM]
  Here you go, a c++ API download for MySQL.API stands for Application Programming Interface.ODBC wrapper is also available, if speed isn't really an issue.(The MySQL code itself is lighting fast!)LinkNow, to your question:1: You can very well use local files, as well as server-resided files as databases.By the way, the speed is _always_ an issue if you're going to publish a game  [edited by - Nik02 on August 1, 2003 2:41:57 AM];  Here''s a few pointers that may clear things up:1) If you''re doing a multi-player game, there are two kinds of data: shared, static data (terrain, meshes, etc), and shared, dynamic data (where everyone is, what their name is, stats, etc).Trying to manage dynamic, shared data using a client-side database is doomed to failure.Trying to put shared, static data in a client-side database works, although files work well, too, for that.2) Databases don''t necessarily need servers. Many database engines allow you to link to a library and open a file on disk as the database file.3) If you want to connect to a remote database for shared data, you don''t need a local server for it; you just need a client library which you can point at a specific IP/port number, and off you go.4) Security is really hard in a multi-user game. So is efficiency (network bytes are the most scarce resource you have). ;  Thank you Nik02,In effect I am wondering if mysql++''s (v1.7.1 is what I''ve got in front of me at the moment; the version the book I have deals with)Connection class can access a local database without mysql being install on the client computer.So far everything I''ve seen is using the (presumably already running) mysql-nt daemon.I''m ignoring speed issues as I figure relivent data can be fetched during load time. By and large I''m more concered with using the database as a file system for a finance program. (I''m getting tired of the spreadsheet I''ve been using  )Thanks for the reply,Feral ;All Quotes from AP:  quote:2) Databases don''t necessarily need servers. Many database engines allow you to link to a library and open a file on disk as the database file.AP, #2 is exactly what I''m after... I''m just not sure how to do that yet. Although how you phrased it it sounds like I just need to dig around the api more. Thank you.quote:1) If you''re doing a multi-player game, there are two kinds of data: shared, static data (terrain, meshes, etc), and shared, dynamic data (where everyone is, what their name is, stats, etc).Trying to manage dynamic, shared data using a client-side database is doomed to failure.Trying to put shared, static data in a client-side database works, although files work well, too, for that.Aye, I''d say dynamic data in a client db would flop because of speed reasons. I don''t have any experience thought As for static data I''d say a db might be good for an index (if queryed at load time)... Probably just as easy to use basic file as the index though)... As you said either would work.quote:4) Security is really hard in a multi-user game. So is efficiency (network bytes are the most scarce resource you have).Aye.. and the more data one has client side the more amunition a malicious use has... I think, but again I have no experience in this field yet.Thank you for your input!/waveFeral ;  Now that you mention it, i have never seen a connection to a raw local file on MySQL.Someone, correct me if i''m wrong, but i think you must have the MySQL server installed, be it a local or remote one. ;  I''ve RTFM but but this isn''t helping me!  Guess they haven’t got to writing the constructor part. (or I''m not reading it right?)(: ;  If you want to use a database on the local machine without running the service, I suggest using something like Microsoft Access. If you use MFC, go with DAO, otherwise go with ADO which is COM based. MS Access doesn''t require you to run the service, it will launch the DLL when you access the database. You just open the connection and you''re ready to go.MS Access is slower then a regular SQL server, but it understands normal SQL code and is easy to use and manage. I am even thinking of using ADO for my MUD server as database interface.Toolmaker   -Earth is 98% full. Please delete anybody you can. ;  Noted about MS Access, thank you Toolmaker.The part about MS Access I didn''t much are for was the convoluted way to access it. At least it seemed convoluted at the time... I''ll have to take another look at it.