Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Stored Procedures for MySQL

Status
Not open for further replies.
Initiate Mage
Joined
Nov 7, 2014
Messages
1
Reaction score
0
THIS HAS NO PRACTICAL PURPOSE


I'm at home for winter break, and I have nothing better to do, so I started adapting the server to run off of a MySQL as opposed to MSSQL.

As you would figure, this is a pretty daunting process. The good news is that the server is designed in such a way that most of the heavy lifting is done through stored procedures in the database. This means that we shouldn't have to make too many changes to the server source code to make this work... right? The bad news is that the servers don't make use of ODBC properly, so I'm going to have to go in the source and change the calls anyway. Sucks right? Yeah... Well, at least after we've made the changes to the source, you'll be able to use the same source code with any other database you can find an odbc adapter for.

Anyway, I'll be updating this post as I make progress, and I'll try to make comments explaining what I can figure out about the database. Feel free to correct any mistakes I make.

You can test these by creating MySQL DSNs in odbcad32.exe, and naming them properly. You'll have to go into the source code and change references to the stored procedures as well to make it work. Here's an example:

Code:
// /ACCOUNTSERVER/DBManager.cpp

sprintf( qryAccount, "LOGINJOIN_STR '%s', '%s'", Gu, szAccount );
[SIZE=5][SIZE=2]
// Should be changed to...
[/SIZE][/SIZE][SIZE=5][SIZE=2]
[/SIZE][/SIZE]sprintf( qryAccount, "{CALL LOGINJOIN_STR ('%s', '%s)}'", Gu, szAccount );


Green = Mostly Usable
Orange = Partially Usable
Red = Not Usable

ACCOUNT_DBF
View attachment account_dbf.sql.txt

Status: 15%

Todo
  • ACCOUNT_STR (unused in source)
  • CREATE_ACCOUNT_STR (unused in source)
  • LOGIN_RELOAD_STR (unused in source)
  • sp_UpdateAccountPassword (unused in source)
  • usp_ChangeEmail (unused in source)
  • usp_ChangePW (unused in source)
  • usp_CreateNewAccount (unused in source)
  • usp_MessengerList (unused in source)
  • usp_og_ChangePassWord (unused in source)
  • USP_PCZoneIP_Check
  • usp_UpdateCashInfo (unused in source)

LOGGING_01_DBF

View attachment logging_01_dbf.sql.txt

Status: 80%

Todo
  • Fix usp_ElectionStat
  • Fix usp_Log_Ins_Dungeon_Insert
  • LOG_RESET_STR (unused in source)
  • uspTransferItemLog (unused in source)
  • uspTransferLevelupLog (unused in source)
  • uspTransferLog (unused in source)
  • uspTransferLoginLog (unused in source)
  • uspTransferTradeLog (unused in source)

CHARACTER_01_DBF

Status: 05%

Todo
  • Too much to even list right now


 

Attachments

You must be registered for see attachments list
Last edited:
Newbie Spellweaver
Joined
Jul 16, 2014
Messages
5
Reaction score
0
Actually, I think moving logic from 1 Database engine to another will not make things better. Logic should be in the application rather than the Storage.

So if you would implement the stored procedures in the server and not in MySQL that would make switching to another database engine in the future much easier as it would be dumb storage.
 
Status
Not open for further replies.
Back
Top