Im sure you can use the uniface provided encrypt/decrypt routines to have something more unreadable in memory and decode it wherever you need it.

But is it worth all that because at least in the variable you have the readable text.

SO the best advice would be: do not store $logstr$ at all.

we have several database (schemas) so while using sql statement $logstr$ is used to login to those
for eg
1)we have syabse db which has datbase a,b,c
2)for the first time when uniface logs in (for example a), it sets this $logstr$ for username and password by prompting to user
3)next time when it tries to login into b it checks $logstr$ , if it has value it logs in without asking for password

Is this problem because I have used component variable?

Hi lalit,

in fact it does not matter what kind of variable it is:

If you store it for your user's convenience, ist is "visible" somewhere in the memory.
The alternative is (for secutities sake) to prompt the user for each database for the password.
 

But at least when you send the logon-info to your database; someone with the right tools may pick it up.

So security is an illusion at all

Waht about using a function like this:

ENTRY LF_LOGSTR
returns string
; ID and PASS also encrypted by surrounding "x"
; ID       = "xmxyx_xixd"
; PASS = "xaxpxaxsxsxwxoxrxd"
RETURN($replace("x|%%id%%%x|%%pass%%%",1,"x","",-1)
END:

...

OPEN LF_LOGSTR(),"DEF"

So there is not hint in memory about the id and/or password.

Okay, the (parameter) stack could hold informations about the logstring, but only for a short time.

Ingo