oops...changed the SA password

[oaksong]

I had a web page that worked very nicely until I changed the SA
password.
The page used data widgets for connectivity to SQL server.
I changed the password in the Server Explorer link, but the code gets
to the .fill method and gives me an error that SA can't login.
I've now spent several hours futzing with the widgets, reconnecting to
the database which tests OK, and I still can't get past the .fill.
It's clear that MS buries code somewhere that you don't have access to
and hides the login identity there. I'm on the verge of starting from
scratch to rebuild the app, but that seems a bit excessive.

Any thoughts?

 

[Juan T. Llibre]

So, why don't you change the SA password
back to what it was previously ?

 

[Patrice]

Switch to the code view and see the generated code. It's likely hardcoded
there. Depending on how you have done, you might have to do that in multiple
pages(search/replace will likely help).

Else details such as ASP.NET Version and the exact "widget" you used may
help...

 

[Mark Rae]

I had a web page that worked very nicely until I changed the SA
password.

There are several issues here:

1) In the first instance, you need to get your system back up and working,
so change the sa password back to what it was previously, as Juan
mentioned...

2) Create a specific SQL Server user (or role) for your ASP.NET app to use,
which has no more permissions than it actually needs.

3) Amend your SQL Connection string(s) to connect using the newly created
user or role.

4) Change the SA password again.

5) Verify that your ASP.NET app still works - if not, return to 1)

6) Fire immediately the person who initially set up the system to connect to
SQL Server with the SA password...

 

[oaksong]

Thanks for all the comments.

Juan: The short answer is I didn't want the particular password to be
viewable in certain situations, which it's not worthwhile going into
here.

Patrice: I went through all the generated code, and in fact reset that
SQL connection to Network, and was still seeing an error based on SA,
which was no longer in the code.

Mark: I'll fire myself right now. It's not a production system. I am
playing around with a concept and was trying to set up some test
situations. I'm actually rather glad this happened earlier rather than
later. And I am going to create a seperate login for the system, since
it appears that I will have to recreate it from scratch. I was looking
at the SDK (VS 2003) File menu and there does not appear to be any
method of deleting a project or solution, which puts me in a small
bind. I suspect I will be forced to go and edit the registry to remove
the project from the startup. Hopefully that will let me start over.
Overall I'm very unhappy with some of the behavior of the SDK, but
that's not unusual. I frequently find the Microsoft misses a lot of
simple things.

 

[Kevin Spencer]

I frequently find the Microsoft misses a lot of

simple things.

ROFLMOD. That statement is just dripping with irony...

--

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Juan T. Llibre]

If you don't want the password to be viewable, then you
should setup Windows authentication for SQL Server
and create a Login for the Machinename\ASPNET account
if you are using IIS 5, or Machinename\NETWORK AUTHORITY
if you are using IIS 6.0.

Add that login to the Users for the databases you need to access,
and give it the appropiated permissions.

Then, using "integrated security" in your connection string
will shield all passwords from prying eyes.

re:

there does not appear to be any method of deleting a project or solution

Just backup the files if you want to save them, delete the virtual
directory using the Internet Service Manager, and delete the project
directory from wherever VS 2003 is saving the files.

The project will disappear from the VS 2003 list of projects.

You can later create a new project and use "add existing files"
to test your code file by file.

 

[Scott Allen]

Have you looked inside the web.config file? Most of the drag and drop
operations that need a database connection will stash away an entry in
the <connectionStrings> settings of web.config. You can encrypt these
settings with the aspnet_regiis tool easily, if you want to make them
less visible.

 

[oaksong]

And the answer is:

I wasn't paying attention to the little message that said the build
failed. And I didn't connect that with the DLL not getting updated.
Which meant the current code was not getting changed and the DLL still
had 'old' code.

I've since figured out why the build was failing and, having remedied
that, and have relatively more functionality than previously. I did
start fresh. I also had some painful moments when the DESIGN screen
would refresh and lose either all my widgets or all my data connection
elements, which I would then get to recreate. Only Bill knows what
caused that behavior, maybe.

Again, I'm glad some of you have found this amusing and thanks to all
of you for the follow up comments.