Update: The stored procedure below applies only to ASE pre-15.0.2.
For how to apply the same trick in 15.0.2 or later, see the quiz question for June 2013.
A blank password
(a.k.a. a 'null' password) only exists in ASE for the
sa login when a new server is created. Officially, you
cannot set a password for an ASE login to blanks
yourself (and indeed, it is a better idea to use a strong and non-blank password instead). Unfortunately, you sometimes really need this
Consider the following situation: you've left the sa
password blank for a long time, but now you finally
changed it to some normal value (as is indeed
recommended). Next day, some important applications don't
work anymore because they are using a hard-coded, blank
sa password. Now you need to set the sa password back
to blanks, but there is no way to do this...
This would indeed be a good reason for panic, had there
not been a stored procedure called sp_blank_password
which sets the sa password back to blanks. In fact, it
can set the password of *any* login to blanks.
A more detailed discussion of this
issue can be found in the article "How to set ASE
login passwords (back) to blank", which was
published in the Q2 1999 issue of the
ISUG Technical Journal
The full article is also available here
. A PDF
version of the original publication can also
be downloaded from here
Note: in June 2000, additional
information was added to this article about
new ASE 12.0 features which allow a blank password to be
set in an alternative way.
- Decompress the file (using
PKZIP or WinZip) & run the script as follows:
isql -Usa -P<sa-password> -S<servername>
- You're basically ready now.
Try it out as follows by creating a new login and then setting its password to blank:
exec sp_addlogin mytestlogin, verysecret
exec sp_blank_password mytestlogin
- You should now be able to log
into the server using this login and a blank password as follows:
isql -Umytestlogin -P -S<servername>
- The procedure comes with
encrypted blank passwords for the major Sybase
platforms. It may be possible you're running on a
different platform, however, for which no value
is provided here. If this happens, just follow
the instructions which are printed on the screen
during installation to determine the value for
Currently, values are included for Windows NT,
Solaris, Digital Unix, AIX, HP-UX, UnixWare,
Linux and OpenVMS.
- Note: in September 1999, a bug
was fixed in the script (thanks to Scott Wright):
the platform check was looking for the string
"/Sun" in the @@version variable,
which, in case the server code happened to be
compiled on a Sunday, caused the code to believe
it was running on Sun-Solaris while it really was
on a different platform.
For further background information
and instructions for use, see the header of the