PLEASE REPORT: on testing of Server once again!

Keith DeLong delong at redcort.com
Wed Apr 30 20:07:48 CDT 2003


Ruslan,
 
> Keith,
> 
> 1) I think we do not need server.AddDB. We can do this via db.Create()

I'm not thinking of it as a substitute for create. I'm looking for a way to
modify master.vdb remotely -- .AddDB is for moving existing dbs online with
the server. It adds an entry to the databases table in master.vdb

>   and probably deleteDB() also not needed if ad SQL command
>   SqlExecute( "DELETE DATABASE name" )

Same thing -- this just deletes dbname from databases table in master.vdb.
You may want to take a db offline (like a remotely created backup) so that
it is not available to the server. Removing dbname from the databases table
could be a good security mechanism.
 
> 2) AddUser, and DeleteUser() -- good idea.
> 3) server.available -- agree
> 4) server.dbexists (dbname) --
> 
> 
>>      //syntax
>>      dim server as vserver
>>      server = new vserver(hostname, servername, user, password)
> 
> They often name this as Connection class.
 
>>      mDataBase = new MyDataBase(server)
> 
> Here I am not agree.
> Why to more user/password from Vdatabase object?

I'm trying to think of the server in OOP terms :-). If a server connection
is an object, the  username and password seem like they belong to the server
object. The database then opens in reference to the server object.

> Although server really must have user/pass parameters, because only
> administrator must be able add/delete users and other commands.

Okay, so my server object is an administrative and yours is a user based
object. Does this makes sense?
 
>>      res = mDataBase.Create(dbname, 1, 32 * 1024 )
>>      //or
>>      res = mDataBase.open( dbname )
>> 
>> 
>>      mDataBase2 = new MyDataBase2(server)
> 
> And here can be problem.
> 
> Look. Some User with some password can have right to access DatabaseA on
> server. But this DO NOT means that he must be able access all other
> databases on this server.

I didn't understand this. The master.vdb didn't seem to allow for this. The
master.vdb only has user table (name and password) and databases (name and
path) table. 

Within a server, how do we associate a user to a particular db?
 
> So combination  { Database / User / Password } must be unique.

If the above is true then it makes more sense. I'm sure I'm missing
something here. Aren't all dbs authenticated through the one master.vdb? The
server connection would give me access to this db and thus authenticate for
all dbs in the server.

I'm thinking of a group of separate databases -- maybe a settings db, a
dataDB, partsDB, etc all running in the same server master.vdb.

It seems a sever object that authenticates me to a server port (port, name,
password) would give me an object I could reuse in my application to open,
access, write, create and delete all dbs in the master.vdb.

> Okay, let's we start implement this dieas step by step, and later polish
> them.

Happy coding :-)

Keith



More information about the Valentina mailing list