Showing posts with label network. Show all posts
Showing posts with label network. Show all posts

Tuesday, March 27, 2012

datasource on remote SQL server?

Disclaimer: I'm a web developer, not a DBA or network admin, so if the following is a totally stupid question, please be gentle--

I am trying to come up with a somewhat decent testing environment (they have no staging area) for a client for whom I'm converting a static HTML site to ASP pulling content from SQL Server.

I'm running Windows 2000 Professional at home and its slightly-watered-down version of IIS webserver, which is fine for testing ASP that doesn't talk to a database. My question is, is there any way that my home webserver can talk to their production SQL Server installation?

My working setup is this--I can connect via Remote Desktop to their webserver machine, which has a copy of Enterprise Manager installed, which has a database registration for a SQL Server installation on a physically separate machine. Given those couple of degrees of separation, I have no idea how locked-down the actual SQL Server box might or might not be as far as the outside world goes.

So, several questions:

Is there a way, without access to the machine console, to figure out if the SQL Server box has an Internet IP address I can try to set up as an ODBC DSN?

Given access to Enterprise Manager for that SQL Server install, are there settings I can check and/or configure to make this happen?

And if this is the sort of thing I wouldn't be able to resolve myself, is there anything specific I can ask the client's tech staff to see if I can get what I need?

I hope this is coherent. If the answer is "dude, you need to talk to the network admin" I'll do that... it's just I'd always rather learn how to do something myself when it's possible :)Since you can get a terminal session going between yourself and them, it sounds like you can get onto their network. If you are using the webserver's name to connect to the webserver, then you are using their DNS, and you are practically all set.

begin rant()
As a rule, no IP addresses should be used in code, except for raw
testing. Any server should be addressed by it's DNS or other network
name. This way, if an IP address changes, or a machine is replaced,
the application is not affected.
end rant;

If you can not use a DNS name (I have seen some VPN connections forbid using others' DNS Servers) for the SQL server on your local machine, and you must use IP addresses, I would say ping the name of the SQL Server, and see what comes back. Then ping that address from your local machine to make sure that you can get there.

As for how to connect to the DB itself, you will have to talk to their administrator. Ideally you should get a read-only login for the particular database you want to connect to. Many small shops use the sa login for all of their apps, but that is not very secure.

Hope this helps.|||Hi, thanks for your response.

I had tried creating a new datasource using the SQL server machine name while connected via terminal session to the webserver. I get an error:

Connection failed:
SQLState '01000'
SQL Server Error: 53
[Microsoft][ODBC SQL Server Driver][Named Pipes]ConnectionOpen (CreateFile()).
Connection failed:
SQLState: '08001'
SQL Server Error: 6
[Microsoft][ODBC SQL Server Driver][Named Pipes]Specified SQL Server not found.

I feel your pain on IP addresses in code, but I only want it to try to create a datasource on my home machine, since creating a datasource using the machine name doesn't seem to be working. Pinging the SQL box from the webserver console just gets me an internal network IP; a ping of that IP from my home machine (with terminal session running) times out.

In any event, using an external IP, if it exists, would seem preferable to a machine name for my purposes, because it means I don't have to keep a remote desktop session open 24/7 for the next month.

I have no problem connecting to the DB when using Enterprise Manager from the webserver console--it's set up to use Windows authentication--I believe I could ask for & receive SA access if it were necessary though.|||When you get to the second screen of the ODBC Configuration (where it asks for a user and password), click on the Client Configuration button. See if you can change the NetLib to TCP/IP. Sometimes the NetLibs can be a little funny about actually finding a server. This would be on the client's webserver, of course.|||I did try that, in spite of not knowing what the heck I was doing--figured I couldn't break what wasn't work in the first place. No love, though--thanks for the suggestion.

My client is using <a href="http://links.10026.com/?link=http://www.neoteris.com/products.html">Neoteris</a> to manage remote sessions. I don't know much about the technical details of how it works (and because their support pages require a customer id and password, it seems they don't WANT me to know) but I found a diagnostic button to click and I can see where it is mapping a number of machine names on their network to IP addresses in my home network's internal space. I see the webserver machine name there; I don't see the SQL box machine name.

I broke down and emailed my contact to ask if they can set up remote access authorization to the SQL box too--I still don't like the notion of having to keep the Neoteris session (based in a java applet in a web browser) running 24/7. It's gonna be fun the first time my DSL hiccups and the client calls me all "I can't connect to the test site" and I'm on the other side of town--but it would be a solution.

Sunday, March 25, 2012

DATASOUCE problem with SQL CLIENT from POCKET PC

I've been struggling to put together an install setup for an app on a pocket
pc. This app accesses a network SQL 2005 server.
I finally got things working - found some .CAB's that needed to be installed
on the PPC for SQL CE and SQL CLIENT.
But now I'm getting an odd error. In my SQL connection string I'm
specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005 on
our domain). But instead it's connecting to a laptop SQL 2000 instance -
laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
info.
How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
install?Hello Steve!
Correction: It's "Data Source=" or "Server=" not "DATASOURCE="
You may find the latest version of SQL Server CE from the following link:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3
Ekrem Ã?nsoy
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:7508FAC3-F20E-4AB9-85AF-8E02782751D2@.microsoft.com...
> I've been struggling to put together an install setup for an app on a
> pocket
> pc. This app accesses a network SQL 2005 server.
> I finally got things working - found some .CAB's that needed to be
> installed
> on the PPC for SQL CE and SQL CLIENT.
> But now I'm getting an odd error. In my SQL connection string I'm
> specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005
> on
> our domain). But instead it's connecting to a laptop SQL 2000 instance -
> laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
> info.
> How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
> install?|||I have "DATA SOURCE=SPSERVER" - I typed it wrong in my post.
How about the latest download for SQL CLIENT for PPC?
"Ekrem Ã?nsoy" wrote:
> Hello Steve!
>
> Correction: It's "Data Source=" or "Server=" not "DATASOURCE="
> You may find the latest version of SQL Server CE from the following link:
> http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=85e0c3ce-3fa1-453a-8ce9-af6ca20946c3
>
> --
> Ekrem Ã?nsoy
>
> "Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
> news:7508FAC3-F20E-4AB9-85AF-8E02782751D2@.microsoft.com...
> > I've been struggling to put together an install setup for an app on a
> > pocket
> > pc. This app accesses a network SQL 2005 server.
> >
> > I finally got things working - found some .CAB's that needed to be
> > installed
> > on the PPC for SQL CE and SQL CLIENT.
> >
> > But now I'm getting an odd error. In my SQL connection string I'm
> > specifying DATASOURCE=SPSERVER (which is the network server for SQL 2005
> > on
> > our domain). But instead it's connecting to a laptop SQL 2000 instance -
> > laptop name is FPS-LAP-SZ. I've googled for a bug like this and found no
> > info.
> >
> > How do I guarantee the latest .CAB's for SQL CE and SQL CLIENT for my PPC
> > install?
>

Friday, February 17, 2012

Database with Single user mode

Hi,
I have a problem, where in a particular database is in single user mode (after it was restored). Now somebody in the network has logged onto this database as "sa", because of which am not able to loggin, even though I know "sa" username/pwd. Is there a way of killing the connected user session, so that I can login? Also, would it be possible to find, from which machine it was logged on earlier?
Thanks very much
GYKGYK
The problems with letting people have SA access huh. If
someone is logged on using sa, you should try to find out
what they are doing, rather than just kill them. Or are
you one of those places where everyone knows and uses the
sa account?
Either using sp_who or viewing process info through
enterprise manager you can see Host Name, ie the PC they
are logged on from. How easy that is to resolve depends on
how accessable that info is in your company.
Regards
John|||Hi John,
Thanks for the response. This server is a development server, and unfortunately every user has sa access.
Now that the database is in single user mode, and somebody else has already logged in, I am not able to login. So there is no question of using sp_who system proc. I basically, want to know if there is any method by which one can login into a database with single user mode, when other use has already logged in.
Or let me frame my question like this..
what if a user has logged into a single user mode database and go home. Does this mean other users can't login at all? I guess there should be some alternative..
Thanks
GYK
-- John Bandettini wrote: --
GYK
The problems with letting people have SA access huh. If
someone is logged on using sa, you should try to find out
what they are doing, rather than just kill them. Or are
you one of those places where everyone knows and uses the
sa account?
Either using sp_who or viewing process info through
enterprise manager you can see Host Name, ie the PC they
are logged on from. How easy that is to resolve depends on
how accessable that info is in your company.
Regards
John|||The question is whether the server is in single user (-m) or the database.
If the server: You shouldn't run the server in this mode normally. Only when
restoring the master database.
If the database: Kick out the user (KILL).
--
Tibor Karaszi, SQL Server MVP
Archive at:
http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"GYK" <anonymous@.discussions.microsoft.com> wrote in message
news:427A3F1F-685C-4F42-8194-D7127D3454CF@.microsoft.com...
> Hi John,
> Thanks for the response. This server is a development server, and
unfortunately every user has sa access.
> Now that the database is in single user mode, and somebody else has
already logged in, I am not able to login. So there is no question of using
sp_who system proc. I basically, want to know if there is any method by
which one can login into a database with single user mode, when other use
has already logged in.
> Or let me frame my question like this..
> what if a user has logged into a single user mode database and go home.
Does this mean other users can't login at all? I guess there should be some
alternative..
> Thanks
> GYK
> -- John Bandettini wrote: --
> GYK
> The problems with letting people have SA access huh. If
> someone is logged on using sa, you should try to find out
> what they are doing, rather than just kill them. Or are
> you one of those places where everyone knows and uses the
> sa account?
> Either using sp_who or viewing process info through
> enterprise manager you can see Host Name, ie the PC they
> are logged on from. How easy that is to resolve depends on
> how accessable that info is in your company.
> Regards
> John
>|||You can still get the info, run sp_who from master
database or use enterprise manager. You are getting
process information for the entire server, you don't need
to be in the user database.
Have you tried to issue a kill? In enterprise manager
double click the process id, see if you get the option to
kill. An alternative might be to get your NT/Windows admin
to kill the network connection based on the host id.
Hope this helps
John