I never had this problem between two WIN2k servers.
I have a new Win2003(XP) server with SQL 2000 and an old Win2k server
with SQL 7. I'm trying to run a query for data from a table on 7 joined
to a table on 2000 inserting into a table on 2000.
Regardless of which server hosts the query I get an error about user
'null' not being a trusted SQL server connection. Same error whether I
run the query in QAnalyser or DTS.
I have admin rights on both servers and both DBMs.
I DON'T have a domained network; windows networking. Since I've done
things between the 7 server and my dev server (W2k/SQL2000) I'm guessing
it's something to do with a stricter W2003 and seperate, but same
username, identities on each local machine.
Can anybody tell me what the next step is?
thx
md
*** Sent via Developersdex http://www.codecomments.com ***Not a lot of information on the error but I'm guess you are
using a linked server that is set up to use the current
users security context. And you are logging into SQL Server
using windows authentication.
It's not clear from which box you are initiating this from.
Even if it was initiated from SQL 2000, sounds like you
would still need to use a SQL login for the linked server.
-Sue
On Tue, 13 Sep 2005 14:58:37 -0700, M D <mardukes@.aol.com>
wrote:
>I never had this problem between two WIN2k servers.
>I have a new Win2003(XP) server with SQL 2000 and an old Win2k server
>with SQL 7. I'm trying to run a query for data from a table on 7 joined
>to a table on 2000 inserting into a table on 2000.
>Regardless of which server hosts the query I get an error about user
>'null' not being a trusted SQL server connection. Same error whether I
>run the query in QAnalyser or DTS.
>I have admin rights on both servers and both DBMs.
>I DON'T have a domained network; windows networking. Since I've done
>things between the 7 server and my dev server (W2k/SQL2000) I'm guessing
>it's something to do with a stricter W2003 and seperate, but same
>username, identities on each local machine.
>Can anybody tell me what the next step is?
>thx
>md
>*** Sent via Developersdex http://www.codecomments.com ***
Showing posts with label servers. Show all posts
Showing posts with label servers. Show all posts
Friday, March 30, 2012
Friday, March 23, 2012
noob question of how to combine two tables from two different servers.
I got two tables from 2 different server A and B.
I do a OLEDB source [server A] with "select ID, currencyNo, exchangerate from table A"
I do another OLEDB [ server B] source with "select currencyNo, currencyName from table B"
i want to combine these two OLEDB sources with a resultset
"select ID, currencyNo, currencyName, exchangerate from table A , B
where A.currencyNo = B.CurrencyNo"
how do i do this in SSIS? sorry if i m a noob. I dun want to use linked servers. can someone help?
Running that kind of query is not something that SSIS is going to do magically for you. You have to ask your DBA to set link servers (assuming they are SQL Server).
Other option is to use 2 OLE DB source and then use a Merge Join transformation to merge both sources in a single output.
Both solutions may impact negatively the performance; but that will be really an issue depending in other factors like volume of data and hardware configuration.
A third option is to break work in 2 pieces; first extract data from each table and load it in a common database and then once both tables are in the same database you can use a single ole db source component.
As you can see you have several options
Rafael Salas
|||Just remember that if using a Merge Join transformation, your inputs need to be sorted on the key. Also, it is best to do the sort in your source SQL if possible, and avoid using the sort transformation in SSIS.Phil|||
i got problems using the merge join....it say i need to sort the data....
|||That's what I said you needed to do in my previous post.|||Thanks, i solved my problem!!Monday, March 12, 2012
Non-admin Citrix users cannot connect to SQL Server
We have an application that accesses a SQL 2000 server that is running on
several Citrix servers. Recently users started getting a message from the
application that there was a catastrophic failure when connecting to SQL
server. This was only happening if the user was not an administrator on the
Citrix server.
I tried connecting to SQL server from Enterprise Manager and Query Analyzer.
If I was logged on as an admin it worked, but if not, it did not work. In
Query Analyzer if I tried to log on to SQL server using a bad password, I got
back a message about bad user or password. When I put in the correct
password (or if using integrated security) the screen briefly acts like it is
connecting but then the entire isqlw program shuts down. Enterprise manager
shuts down when I try to connect to a server. As a non-admin user I am able
to connect using ISQL.exe.
We've checked on rights to the SQL files and everything looks OK. Is there
anything else to check?
Thanks
LehrSJ
Hello there,
I would like to suggest you applied the SQL 2000 SP4 first.
And please let me know the error log in the SQL Server.
This issue may related with some permission of folder. If you use the SQL
Authentication to connect the SQL server, did this issue occur?
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
several Citrix servers. Recently users started getting a message from the
application that there was a catastrophic failure when connecting to SQL
server. This was only happening if the user was not an administrator on the
Citrix server.
I tried connecting to SQL server from Enterprise Manager and Query Analyzer.
If I was logged on as an admin it worked, but if not, it did not work. In
Query Analyzer if I tried to log on to SQL server using a bad password, I got
back a message about bad user or password. When I put in the correct
password (or if using integrated security) the screen briefly acts like it is
connecting but then the entire isqlw program shuts down. Enterprise manager
shuts down when I try to connect to a server. As a non-admin user I am able
to connect using ISQL.exe.
We've checked on rights to the SQL files and everything looks OK. Is there
anything else to check?
Thanks
LehrSJ
Hello there,
I would like to suggest you applied the SQL 2000 SP4 first.
And please let me know the error log in the SQL Server.
This issue may related with some permission of folder. If you use the SQL
Authentication to connect the SQL server, did this issue occur?
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Non SMTP email
Hi,
On my network exchange servers don't use smtp.
Is it possible to configure RS to email using other methods link MAPI,
... ?The delivery extension that shipped with RS only works with SMTP. You would
need to write you own delivery extension to do this.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
<kamara1@.yahoo.com> wrote in message
news:1105611912.754219.160300@.f14g2000cwb.googlegroups.com...
> Hi,
> On my network exchange servers don't use smtp.
> Is it possible to configure RS to email using other methods link MAPI,
> ... ?
>
On my network exchange servers don't use smtp.
Is it possible to configure RS to email using other methods link MAPI,
... ?The delivery extension that shipped with RS only works with SMTP. You would
need to write you own delivery extension to do this.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
<kamara1@.yahoo.com> wrote in message
news:1105611912.754219.160300@.f14g2000cwb.googlegroups.com...
> Hi,
> On my network exchange servers don't use smtp.
> Is it possible to configure RS to email using other methods link MAPI,
> ... ?
>
Friday, March 9, 2012
Non default port
I am using SQL 2005 and have multiple instances installed on multiple
servers. None are on the default port. When I connect to box 01
without specifying the port in the connection string, it connects.
But on box 02, it will only connect to the instance if I specify the
port name. Is this because it will only connect to the default
instance without specifying a port? or is there something else I need
to have setup on box 02 to make this work?
thanks in advance :)See if the SQL Server Browser service is started on box 02.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Victag" <miketaggart@.gmail.com> wrote in message
news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>I am using SQL 2005 and have multiple instances installed on multiple
> servers. None are on the default port. When I connect to box 01
> without specifying the port in the connection string, it connects.
> But on box 02, it will only connect to the instance if I specify the
> port name. Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
> thanks in advance :)|||> Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
Check to ensure the SQL Browser service is running as Tibor suggested.
Another possible cause is that UDP port 1434 is blocked.
When you connect to the default instance, TCP port 1433 is used by default.
When you connect to a named instance without a specifying a port, the client
requests a list of the named instances and corresponding ports via UDP port
1434 (this is the SQL Browser service). The client then determines the
named instance port.
--
Hope this helps.
Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/
"Victag" <miketaggart@.gmail.com> wrote in message
news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>I am using SQL 2005 and have multiple instances installed on multiple
> servers. None are on the default port. When I connect to box 01
> without specifying the port in the connection string, it connects.
> But on box 02, it will only connect to the instance if I specify the
> port name. Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
> thanks in advance :)|||On Mar 13, 4:26=A0am, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> Check to ensure the SQL Browser service is running as Tibor suggested.
> Another possible cause is that UDP port 1434 is blocked.
> When you connect to the default instance, TCP port 1433 is used by default=.
> When you connect to a named instance without a specifying a port, the clie=nt
> requests a list of the named instances and corresponding ports via UDP por=t
> 1434 (this is the SQL Browser service). =A0The client then determines the
> named instance port.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>
> >I am using SQL 2005 and have multiple instances installed on multiple
> > servers. =A0None are on the default port. =A0When I connect to box 01
> > without specifying the port in the connection string, it connects.
> > But on box 02, it will only connect to the instance if I specify the
> > port name. =A0Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> > thanks in advance :)- Hide quoted text -
> - Show quoted text -
Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?|||<<Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?>>
We can only explain how things work:
When you connect to a default instance (no backslash and instance name), the data access components
will connect to port 1433. The SQL Server service by default listens to 1433 for a default instance
(well-known port).
The port number for a named instance is determined dynamically the first time you start the
instance. SQL Server asks Windows for an available port, uses it and stores the port number in the
registry (as you can see using SQL Server Configuration Manager). It will try to use the same port
number on subsequent start-ups.
If you from the client app only specify machine name/IP backslash instancename, then you need some
component to translate this instance name to a port number. That component is SQL Server Browser
service. The client data access components connects to the SSB service using port 1434 UDP and
passes the instance name, and the SSB service returns the port number. You can also from the client
app specify machine/IP comma portnumber, so there would now be no use for the SSB service. SQL
Server 2000 didn't come with an SSB service so for 2000 the database engine did this job (listening
on port 1434).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Victag" <miketaggart@.gmail.com> wrote in message
news:bee0415f-6523-45e7-9d46-ad9a01846809@.d62g2000hsf.googlegroups.com...
On Mar 13, 4:26 am, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> Check to ensure the SQL Browser service is running as Tibor suggested.
> Another possible cause is that UDP port 1434 is blocked.
> When you connect to the default instance, TCP port 1433 is used by default.
> When you connect to a named instance without a specifying a port, the client
> requests a list of the named instances and corresponding ports via UDP port
> 1434 (this is the SQL Browser service). The client then determines the
> named instance port.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>
> >I am using SQL 2005 and have multiple instances installed on multiple
> > servers. None are on the default port. When I connect to box 01
> > without specifying the port in the connection string, it connects.
> > But on box 02, it will only connect to the instance if I specify the
> > port name. Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> > thanks in advance :)- Hide quoted text -
> - Show quoted text -
Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?|||Hi,
You can access named instances (if you know port number) in this way:
tcp:server_name,port_number
--
Regards,
anxcomp|||On Mar 13, 11:12=A0am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> <<Thanks folks! =A0I have checked and the Browser service is disabled on
> both boxes (event he working one), so I could try turning it on, but I
> would rather explain/understand what the difference is between these
> boxes. =A0I have also confirmed that no ports are blocked at all. =A0Any
> other suggestions?>>
> We can only explain how things work:
> When you connect to a default instance (no backslash and instance name), t=he data access components
> will connect to port 1433. The SQL Server service by default listens to 14=33 for a default instance
> (well-known port).
> The port number for a named instance is determined dynamically the first t=ime you start the
> instance. SQL Server asks Windows for an available port, uses it and store=s the port number in the
> registry (as you can see using SQL Server Configuration Manager). It will =try to use the same port
> number on subsequent start-ups.
> If you from the client app only specify machine name/IP backslash instance=name, then you need some
> component to translate this instance name to a port number. That component= is SQL Server Browser
> service. The client data access components connects to the SSB service usi=ng port 1434 UDP and
> passes the instance name, and the SSB service returns the port number. You= can also from the client
> app specify machine/IP comma portnumber, so there would now be no use for =the SSB service. SQL
> Server 2000 didn't come with an SSB service so for 2000 the database engin=e did this job (listening
> on port 1434).
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph=
ttp://sqlblog.com/blogs/tibor_karaszi
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:bee0415f-6523-45e7-9d46-ad9a01846809@.d62g2000hsf.googlegroups.com...
> On Mar 13, 4:26 am, "Dan Guzman" <guzma...@.nospam-
>
>
> online.sbcglobal.net> wrote:
> > > Is this because it will only connect to the default
> > > instance without specifying a port? or is there something else I need
> > > to have setup on box 02 to make this work?
> > Check to ensure the SQL Browser service is running as Tibor suggested.
> > Another possible cause is that UDP port 1434 is blocked.
> > When you connect to the default instance, TCP port 1433 is used by defau=lt.
> > When you connect to a named instance without a specifying a port, the cl=ient
> > requests a list of the named instances and corresponding ports via UDP p=ort
> > 1434 (this is the SQL Browser service). The client then determines the
> > named instance port.
> > --
> > Hope this helps.
> > Dan Guzman
> > SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> > "Victag" <miketagg...@.gmail.com> wrote in message
> >news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...=
> > >I am using SQL 2005 and have multiple instances installed on multiple
> > > servers. None are on the default port. When I connect to box 01
> > > without specifying the port in the connection string, it connects.
> > > But on box 02, it will only connect to the instance if I specify the
> > > port name. Is this because it will only connect to the default
> > > instance without specifying a port? or is there something else I need
> > > to have setup on box 02 to make this work?
> > > thanks in advance :)- Hide quoted text -
> > - Show quoted text -
> Thanks folks! =A0I have checked and the Browser service is disabled on
> both boxes (event he working one), so I could try turning it on, but I
> would rather explain/understand what the difference is between these
> boxes. =A0I have also confirmed that no ports are blocked at all. =A0Any
> other suggestions... Hide quoted text -
> - Show quoted text -
Thanks again. I have made progress and found that the boxes that are
not working have many client aliases created on them, some of which
appear to be invalid. When I deleted the aliases that did not exist
on the server that is working, it fixed them. So now that I know how
to fix it, I am curious to know how these bad aliases got created
since we did not create them manually.|||"Victag" wrote:
>I am curious to know how these bad aliases got created
> since we did not create them manually.
Did you install Visio? For example Visio installation process create for me
some alias. I have to delete it manually.
Regards,
anxcomp
servers. None are on the default port. When I connect to box 01
without specifying the port in the connection string, it connects.
But on box 02, it will only connect to the instance if I specify the
port name. Is this because it will only connect to the default
instance without specifying a port? or is there something else I need
to have setup on box 02 to make this work?
thanks in advance :)See if the SQL Server Browser service is started on box 02.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Victag" <miketaggart@.gmail.com> wrote in message
news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>I am using SQL 2005 and have multiple instances installed on multiple
> servers. None are on the default port. When I connect to box 01
> without specifying the port in the connection string, it connects.
> But on box 02, it will only connect to the instance if I specify the
> port name. Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
> thanks in advance :)|||> Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
Check to ensure the SQL Browser service is running as Tibor suggested.
Another possible cause is that UDP port 1434 is blocked.
When you connect to the default instance, TCP port 1433 is used by default.
When you connect to a named instance without a specifying a port, the client
requests a list of the named instances and corresponding ports via UDP port
1434 (this is the SQL Browser service). The client then determines the
named instance port.
--
Hope this helps.
Dan Guzman
SQL Server MVP
http://weblogs.sqlteam.com/dang/
"Victag" <miketaggart@.gmail.com> wrote in message
news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>I am using SQL 2005 and have multiple instances installed on multiple
> servers. None are on the default port. When I connect to box 01
> without specifying the port in the connection string, it connects.
> But on box 02, it will only connect to the instance if I specify the
> port name. Is this because it will only connect to the default
> instance without specifying a port? or is there something else I need
> to have setup on box 02 to make this work?
> thanks in advance :)|||On Mar 13, 4:26=A0am, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> Check to ensure the SQL Browser service is running as Tibor suggested.
> Another possible cause is that UDP port 1434 is blocked.
> When you connect to the default instance, TCP port 1433 is used by default=.
> When you connect to a named instance without a specifying a port, the clie=nt
> requests a list of the named instances and corresponding ports via UDP por=t
> 1434 (this is the SQL Browser service). =A0The client then determines the
> named instance port.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>
> >I am using SQL 2005 and have multiple instances installed on multiple
> > servers. =A0None are on the default port. =A0When I connect to box 01
> > without specifying the port in the connection string, it connects.
> > But on box 02, it will only connect to the instance if I specify the
> > port name. =A0Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> > thanks in advance :)- Hide quoted text -
> - Show quoted text -
Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?|||<<Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?>>
We can only explain how things work:
When you connect to a default instance (no backslash and instance name), the data access components
will connect to port 1433. The SQL Server service by default listens to 1433 for a default instance
(well-known port).
The port number for a named instance is determined dynamically the first time you start the
instance. SQL Server asks Windows for an available port, uses it and stores the port number in the
registry (as you can see using SQL Server Configuration Manager). It will try to use the same port
number on subsequent start-ups.
If you from the client app only specify machine name/IP backslash instancename, then you need some
component to translate this instance name to a port number. That component is SQL Server Browser
service. The client data access components connects to the SSB service using port 1434 UDP and
passes the instance name, and the SSB service returns the port number. You can also from the client
app specify machine/IP comma portnumber, so there would now be no use for the SSB service. SQL
Server 2000 didn't come with an SSB service so for 2000 the database engine did this job (listening
on port 1434).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Victag" <miketaggart@.gmail.com> wrote in message
news:bee0415f-6523-45e7-9d46-ad9a01846809@.d62g2000hsf.googlegroups.com...
On Mar 13, 4:26 am, "Dan Guzman" <guzma...@.nospam-
online.sbcglobal.net> wrote:
> > Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> Check to ensure the SQL Browser service is running as Tibor suggested.
> Another possible cause is that UDP port 1434 is blocked.
> When you connect to the default instance, TCP port 1433 is used by default.
> When you connect to a named instance without a specifying a port, the client
> requests a list of the named instances and corresponding ports via UDP port
> 1434 (this is the SQL Browser service). The client then determines the
> named instance port.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...
>
> >I am using SQL 2005 and have multiple instances installed on multiple
> > servers. None are on the default port. When I connect to box 01
> > without specifying the port in the connection string, it connects.
> > But on box 02, it will only connect to the instance if I specify the
> > port name. Is this because it will only connect to the default
> > instance without specifying a port? or is there something else I need
> > to have setup on box 02 to make this work?
> > thanks in advance :)- Hide quoted text -
> - Show quoted text -
Thanks folks! I have checked and the Browser service is disabled on
both boxes (event he working one), so I could try turning it on, but I
would rather explain/understand what the difference is between these
boxes. I have also confirmed that no ports are blocked at all. Any
other suggestions?|||Hi,
You can access named instances (if you know port number) in this way:
tcp:server_name,port_number
--
Regards,
anxcomp|||On Mar 13, 11:12=A0am, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> <<Thanks folks! =A0I have checked and the Browser service is disabled on
> both boxes (event he working one), so I could try turning it on, but I
> would rather explain/understand what the difference is between these
> boxes. =A0I have also confirmed that no ports are blocked at all. =A0Any
> other suggestions?>>
> We can only explain how things work:
> When you connect to a default instance (no backslash and instance name), t=he data access components
> will connect to port 1433. The SQL Server service by default listens to 14=33 for a default instance
> (well-known port).
> The port number for a named instance is determined dynamically the first t=ime you start the
> instance. SQL Server asks Windows for an available port, uses it and store=s the port number in the
> registry (as you can see using SQL Server Configuration Manager). It will =try to use the same port
> number on subsequent start-ups.
> If you from the client app only specify machine name/IP backslash instance=name, then you need some
> component to translate this instance name to a port number. That component= is SQL Server Browser
> service. The client data access components connects to the SSB service usi=ng port 1434 UDP and
> passes the instance name, and the SSB service returns the port number. You= can also from the client
> app specify machine/IP comma portnumber, so there would now be no use for =the SSB service. SQL
> Server 2000 didn't come with an SSB service so for 2000 the database engin=e did this job (listening
> on port 1434).
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph=
ttp://sqlblog.com/blogs/tibor_karaszi
> "Victag" <miketagg...@.gmail.com> wrote in message
> news:bee0415f-6523-45e7-9d46-ad9a01846809@.d62g2000hsf.googlegroups.com...
> On Mar 13, 4:26 am, "Dan Guzman" <guzma...@.nospam-
>
>
> online.sbcglobal.net> wrote:
> > > Is this because it will only connect to the default
> > > instance without specifying a port? or is there something else I need
> > > to have setup on box 02 to make this work?
> > Check to ensure the SQL Browser service is running as Tibor suggested.
> > Another possible cause is that UDP port 1434 is blocked.
> > When you connect to the default instance, TCP port 1433 is used by defau=lt.
> > When you connect to a named instance without a specifying a port, the cl=ient
> > requests a list of the named instances and corresponding ports via UDP p=ort
> > 1434 (this is the SQL Browser service). The client then determines the
> > named instance port.
> > --
> > Hope this helps.
> > Dan Guzman
> > SQL Server MVPhttp://weblogs.sqlteam.com/dang/
> > "Victag" <miketagg...@.gmail.com> wrote in message
> >news:0ef672ad-08dd-49da-8ff6-1abfcf4982bb@.s12g2000prg.googlegroups.com...=
> > >I am using SQL 2005 and have multiple instances installed on multiple
> > > servers. None are on the default port. When I connect to box 01
> > > without specifying the port in the connection string, it connects.
> > > But on box 02, it will only connect to the instance if I specify the
> > > port name. Is this because it will only connect to the default
> > > instance without specifying a port? or is there something else I need
> > > to have setup on box 02 to make this work?
> > > thanks in advance :)- Hide quoted text -
> > - Show quoted text -
> Thanks folks! =A0I have checked and the Browser service is disabled on
> both boxes (event he working one), so I could try turning it on, but I
> would rather explain/understand what the difference is between these
> boxes. =A0I have also confirmed that no ports are blocked at all. =A0Any
> other suggestions... Hide quoted text -
> - Show quoted text -
Thanks again. I have made progress and found that the boxes that are
not working have many client aliases created on them, some of which
appear to be invalid. When I deleted the aliases that did not exist
on the server that is working, it fixed them. So now that I know how
to fix it, I am curious to know how these bad aliases got created
since we did not create them manually.|||"Victag" wrote:
>I am curious to know how these bad aliases got created
> since we did not create them manually.
Did you install Visio? For example Visio installation process create for me
some alias. I have to delete it manually.
Regards,
anxcomp
Saturday, February 25, 2012
No. Of Subscribers in Transactional Replication...
Hi,
I am Using Transactional Replication with Updatable Subscriptions. Is there any limitations in the number of subscribers (Servers) used for this type of replication?
I have a scenario of configuring this replication in 60 Subscribers(Servers). And the replication should be in the Continuous running mode. Will Transactional Replication with Updatable Subscriptions work in this scenario? Or is it meant to work for less than 10 subscribers?
Please reply asap.
Thanks in advance.
Regards,
Swapna.B.
Hi Swapna,
This question has been answered in the following posting.
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=754018&SiteID=1
60 subscribers should be fine for transaction replication. However, you should go over the "Considerations for Using Updatable Subscriptions" in following article.
http://msdn2.microsoft.com/en-us/library/ms151718.aspx
Gary
|||Hi Gary,
Thanks a lot.
Regards,
Swapna.B.
Monday, February 20, 2012
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||
Aranda wrote:
The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
No support for SQL Server Authentication and SSIS !!!!
Hi
I want to manage my servers from a central location and have the ability to manage my packges too. Unfortunatley my servers are across domains which means I have to use SQL Server Login, which isn't a bad thing. However for some bizzare reason I can't connect to Integration Services using this method, only windows authentication which is a complete pain in the butt from a management stand point as I have to copy packages to various servers rather than add them from a central point.
Does anyone know if this bug/feature or what ever Microsoft is calling it will be fixed or know of any workarounds.
Thanks
I have no problem with SSIS and SQL-Server-Authentification.|||
I do not even get the option to change the authentication method to SQL Server and the box is greyed out so I can't change the Windows authentication user either.
I do not have any problems inside SSIS, only when I try to connect to the SSIS server from within SQL Server Management Studio in a different domain.
|||I am assuming you are trying to connect to Integration Services from SQL Server Management Studio. You are right, you cannot change the authentication method to SQL Server authentication in this case. This is because it is a separate service, and sql server authentication does not work in this case.|||
This is indeed problematic... if developers for SSIS or even SSAS for that matter have workstations in a domain different from the domain that hosts the Server you cannot deploy packages to the server, you can't create/access SSAS Dbs either.
This means then that any developer must work in the same domain as the server they are trying to deploy to or access (SQL Server mgmt. studio to monitor SSIS packages or to even open a SSAS DB in Visual Studio)
Anyone find a way around this?
Joe.
|||I just found this the hard way. I work for client in a different domain to my workstation and I cannot deploy the app. Like Joe, if someone has already researched this, plxz let us know.
I also have problems with restricted VPN access with locked down ports at the client.
Thanks
|||I have exactly the same problem and also found out the hard way. In fact my problem is a little worse - our client doesn't even HAVE a domain (yes they are a little backward)!
I managed to get the package installed on the client's server after much trial and error (by copying the VS solution to the server, editing my connection managers and debugging then deploying from there. Thankfully they had installed VS on the server).
The bigger problem is now that the clients can never run the SSIS package remotely. What is worse is that SSAS has the same problem - my clients can't browse their cube from Excel or SSMS! The only way I can think of around this is to remote desktop into the server, which is obviously bad.
Thanks in advance for any help / suggestions / comments.
|||If you want to execute a SSIS package remotely, set up a SQL Server Agent job to execute the package. That job can be executed from wherever you like by anyone with SSMS.
-Jamie
|||The bigger problem is now that the clients can never run the SSIS package remotely.
SSIS Service does not provide remote execution, as Jamie suggested - use Agent Jobs instead.
The usual way to get package installed on a machine you can access remotely is to build deployment utility (option in VS SSIS project), copy the folder with deployment utility and run it on the target machine.
What you'll be missing due to lack of domain is
1) ability to remotely store packages, and
2) ability to remotely monitor packages as they are being run, and to terminate these packages.
I just came across this.
I to am frustrated that you can only connect to the SSIS service via windows authentication. I am attempting to connect from my computer(a client running Management Studio) not directly from the machine 'hosting' the SQL Server and SSIS services. When I do this, I obviously have to set myself up with an operating system(Win 2k3 server )account on the server machine but I am only able to connect to SSIS if I am a member of the administrators group. Is this true? Can I connect as someone with less rights/privledges?
Subscribe to:
Posts (Atom)