Changing the name and password of the admin user

[M. A. Sridhar]

Hello,

I run Mckoi in embedded mode with just one user, the one that created the database. I would like to change both the name and the password of that one user. Is there a way to do this? I know I can change the password of that user, but don't know how to change the name.

Thanks in advance.

[Stefaan A Eeckels]

On Tue, 14 Nov 2006 08:44:48 -0800 (PST)

Post by M. A. Sridhar
I run Mckoi in embedded mode with just one user, the one that created
the database. I would like to change both the name and the password
of that one user. Is there a way to do this? I know I can change the
password of that user, but don't know how to change the name.

If you look at the system tables, you'll see that the user name appears
in quite a few of them:

sUSRUserPriv
sUSRUserConnectPriv
sUSRPassword
sUsrGrant

And I might have missed a few. I suppose that changing the name in all
those tables would achieve the renaming of the original user. I have
not tried to do this (yet).

May I ask why you want to change the name? If used the way you
describe, the user name is never visible to the "real user", so why
bother?
--
Stefaan

[M. A. Sridhar]

Post by M. A. Sridhar
I run Mckoi in embedded mode with just one user, the one that created
the database. I would like to change both the name and the password
of that one user. Is there a way to do this? I know I can change the
password of that user, but don't know how to change the name.

If you look at the system tables, you'll see that the user name appears
in quite a few of them:

sUSRUserPriv
sUSRUserConnectPriv
sUSRPassword
sUsrGrant

And I might have missed a few. I suppose that changing the name in all
those tables would achieve the renaming of the original user. I have
not tried to do this (yet).

May I ask why you want to change the name? If used the way you
describe, the user name is never visible to the "real user", so why
bother?
--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh


---------------------------------------------------------------
Mckoi SQL Database mailing list http://www.mckoi.com/database/
To unsubscribe, send a message to mckoidb-***@mckoi.com

Stefan, thanks for the rapid response. My situation is that I redistribute an embedded version of Mckoi to my prospects and customers, and I don't want them reverse-engineering the embedded database to discover each other's login names and passwords. As you say, one can certainly change just the password for each package, but changing the name would make it just a little harder to break into.

Thanks again.



M. A. Sridhar
m_a_sridhar at yahoo dot com

[Stefaan A Eeckels]

On Tue, 14 Nov 2006 12:19:40 -0800 (PST)

Post by M. A. Sridhar
My situation is that I redistribute an embedded version of Mckoi to
my prospects and customers, and I don't want them reverse-engineering
the embedded database to discover each other's login names and
passwords. As you say, one can certainly change just the password for
each package, but changing the name would make it just a little
harder to break into.

I do something similar - what you could do is to create the database
inside the program, and ask the user upon first execution for a name
and password. Then store each user's name and password in a file (no
need to encrypt, user name and password are in clear in McKoi) for
subsequent executions.

You can create the database by catching the exception when connecting
with the

jdbc:mckoi:local://path/to/conf

connect string, then create the conf file and use the string

jdbc:mckoi:local://path/to/conf?create=true

You'll need to create each table as well, which you can do by using the
"CREATE TABLE IF NOT EXISTS" statement. You can also test for the
existence of a table in the system table sUSRTableInfo:

SELECT * from SYS_INFO.sUSRTableInfo A
WHERE A.schema = 'your_schema'
AND A.type = 'TABLE'
AND A.name = 'your_table'

and create it if required. The simple solution is of course to include
all the DDL to create the tables with the connection that creates the
database.

Take care,
--
Stefaan