Game Logic

I have a hard time understanding what the DLL is. Are you saying that there is one DLL, loaded on the client, which implements all of the client, server, socketthread and loginthread code?
Does the client talk directly to the database?
If that is the case, stop right there -- databases should never be readable/writable directly by clients. That's not only poor performance, but also a giant security/cheating hole.
Instead, the typical solution is to use a game/application server. The client talks to the game server, the game server enforces rules, and does data access to the database if needed.

Also, what do you use the database for? If you try to read/write properties each time something changes ("I moved from place X to place Y") then that's not something that you'll want to use a database for -- that should be in RAM, typically in the game server, and the database should only be used for transactional data ("I traded X for Y") or periodic checkpoints ("saves") of player data.

Finally, I think you have way too many threads. It's OK to do things asynchronously, and it's OK to have worker thread pools that run asynchronous tasks, but a thread dedicated to a socket, for example, is not a good way of structuring a program. You will end up with too much locking needed, and all of those threads will eat lots of stack.

Finally, to your "growing RAM store" problem -- have you instrumented the server to see what the memory is used for? How many connections are there? How much is in query cache? Have you tuned the server to the amount of memory you're willing to give it?

The dll have a own connection with the server that I developed and described above.
Clients doesn't connect/talk to database, adUseClient is cursor location for get data for database fastest and adUseServer to write/update, the connection occurs in server.
The database is used to obtain information on loads of items.
Any Socket received by Server is repassed to a new socket thread, its wrong?

procedure TServerThread.ReceiveData(Sender: TObject;
Socket: TCustomWinSocket);
var
SThread:TSocketThread;
begin
{$O+}//Optimization+
SThread:=TSocketThread.Create(Socket,True,True);
{$O-}
end;


The problem is not that you pass sockets between threads; the problem is that you create too many threads.

Server, Login, Info, Prize, DBConnnection Threads is a global thread.
Only the socket thread is created on receive socket.

I still using a Threaded Database Connections or use a own connection for each query?

If you are going for performance, here's some advice:
Each server should create some pool of connections to the database. Exactly how big, and how this is done, varies by database brand. Start by some small number, like 4.
In the server process, run everything as asynchronous tasks. Use a pool of worker threads to work on tasks.
I/O, which includes file system, database queries, and network data, should enqueue or unblock tasks in the worker thread pool. This probably means that you have to use more of a continuation-passing style of programming, and less of a "serial thread" style. But Fibers can help if you really don't want to do this.
In Windows, you implement most of this using the thread pool and I/O completion ports.
In Linux, you implement most of this with epoll and pthreads.
boost::asio is a library that can help with portability, and/or a higher-level API than those basic building blocks.

If your goal is something else, then you'll have to express those goals before anyone can give any better advice :-)