Monday, March 26, 2012
Problem Registering Existing Server
register previously.
I can successfully register it inside the network, i.e., from another
workstation on the network, but when I try to register via a gateway, i.e.,
over the internet I can't. I can ping the server, and the router has port
forwarding setup correctly (port 1433), I've turned off the firewall, and
nothing else has changed that I am aware of, but it just won't respond. I
am confident that the SA password is correct.
I'm stumped. I have remote users who need to access this server, but can't
get in.
Can anyone give me any suggestions. I've tried everything I can imagine.
The one change on this system is that we had to reinstall the Server, and
we've installed CA Antivirus. But I've uninstalled the CA firewall
software, and turned off the Windows Firewall (just to get this up...we had
it running before with SQL traffic allowed).
Any Ideas are welcome!!
Bob
Hi Bob
"Bob Bartel" wrote:
> I am trying to reregister an existing server that we've been able to
> register previously.
> I can successfully register it inside the network, i.e., from another
> workstation on the network, but when I try to register via a gateway, i.e.,
> over the internet I can't. I can ping the server, and the router has port
> forwarding setup correctly (port 1433), I've turned off the firewall, and
> nothing else has changed that I am aware of, but it just won't respond. I
> am confident that the SA password is correct.
> I'm stumped. I have remote users who need to access this server, but can't
> get in.
> Can anyone give me any suggestions. I've tried everything I can imagine.
> The one change on this system is that we had to reinstall the Server, and
> we've installed CA Antivirus. But I've uninstalled the CA firewall
> software, and turned off the Windows Firewall (just to get this up...we had
> it running before with SQL traffic allowed).
> Any Ideas are welcome!!
> Bob
>
It would be safer to use a VPN for this rather than leaving the server open.
http://support.microsoft.com/kb/287932 describes the communication between
the client and server, make sure you are using TCP/IP protcols and the client
is not blocking the returning traffic. If you have set up this correctly you
should be in-undated with people trying to hack in.
John
|||As I mentioned, I have already had this working before. And only shut down
my firewall for this test. I agree a VPN is a good choice and I'll probably
turn it on, but...
But the real problem is that even with the router correctly forwarding 1433
and the firewall configured to allow the traffic, I can't register the
server remotely.
The only thing I can think of that may be effecting it is that I had to
reinstall the server. Can anyone think of anything that would keep remote
users from registering with a new install? Is there some setting on the
server that I neglected to turn back on?
Bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:5E55FAA1-601D-4DED-8E5C-0324E2ED46B6@.microsoft.com...
> Hi Bob
> "Bob Bartel" wrote:
> It would be safer to use a VPN for this rather than leaving the server
> open.
> http://support.microsoft.com/kb/287932 describes the communication between
> the client and server, make sure you are using TCP/IP protcols and the
> client
> is not blocking the returning traffic. If you have set up this correctly
> you
> should be in-undated with people trying to hack in.
> John
|||Hi
"Bob Bartel" wrote:
> As I mentioned, I have already had this working before. And only shut down
> my firewall for this test. I agree a VPN is a good choice and I'll probably
> turn it on, but...
> But the real problem is that even with the router correctly forwarding 1433
> and the firewall configured to allow the traffic, I can't register the
> server remotely.
> The only thing I can think of that may be effecting it is that I had to
> reinstall the server. Can anyone think of anything that would keep remote
> users from registering with a new install? Is there some setting on the
> server that I neglected to turn back on?
> Bob
>
If this is SQL Express you may not have turned on remote access. If this is
a named instance then it would not be using the default ports.
John
|||Its a named instance...where to I specify the port?
bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:1B0EB2A5-8E12-41C2-9D87-5C38176D1783@.microsoft.com...
> Hi
> "Bob Bartel" wrote:
> If this is SQL Express you may not have turned on remote access. If this
> is
> a named instance then it would not be using the default ports.
> John
|||Hi Bob
"Bob Bartel" wrote:
> Its a named instance...where to I specify the port?
> bob
In the SQL Server Configuration manager there will be an entry in the SQL
Server 2005 Network Configuration branch for your instance. This will shows
which protocols are installed and enabled. Right clicking TCP/IP and choosing
properties and on the IP Address tab you can set the protocol to be enabled
and also set the port. You will need to make sure that there are no other
instances using this port.
John
Problem Registering Existing Server
register previously.
I can successfully register it inside the network, i.e., from another
workstation on the network, but when I try to register via a gateway, i.e.,
over the internet I can't. I can ping the server, and the router has port
forwarding setup correctly (port 1433), I've turned off the firewall, and
nothing else has changed that I am aware of, but it just won't respond. I
am confident that the SA password is correct.
I'm stumped. I have remote users who need to access this server, but can't
get in.
Can anyone give me any suggestions. I've tried everything I can imagine.
The one change on this system is that we had to reinstall the Server, and
we've installed CA Antivirus. But I've uninstalled the CA firewall
software, and turned off the Windows Firewall (just to get this up...we had
it running before with SQL traffic allowed).
Any Ideas are welcome!!
BobHi Bob
"Bob Bartel" wrote:
> I am trying to reregister an existing server that we've been able to
> register previously.
> I can successfully register it inside the network, i.e., from another
> workstation on the network, but when I try to register via a gateway, i.e.,
> over the internet I can't. I can ping the server, and the router has port
> forwarding setup correctly (port 1433), I've turned off the firewall, and
> nothing else has changed that I am aware of, but it just won't respond. I
> am confident that the SA password is correct.
> I'm stumped. I have remote users who need to access this server, but can't
> get in.
> Can anyone give me any suggestions. I've tried everything I can imagine.
> The one change on this system is that we had to reinstall the Server, and
> we've installed CA Antivirus. But I've uninstalled the CA firewall
> software, and turned off the Windows Firewall (just to get this up...we had
> it running before with SQL traffic allowed).
> Any Ideas are welcome!!
> Bob
>
It would be safer to use a VPN for this rather than leaving the server open.
http://support.microsoft.com/kb/287932 describes the communication between
the client and server, make sure you are using TCP/IP protcols and the client
is not blocking the returning traffic. If you have set up this correctly you
should be in-undated with people trying to hack in.
John|||As I mentioned, I have already had this working before. And only shut down
my firewall for this test. I agree a VPN is a good choice and I'll probably
turn it on, but...
But the real problem is that even with the router correctly forwarding 1433
and the firewall configured to allow the traffic, I can't register the
server remotely.
The only thing I can think of that may be effecting it is that I had to
reinstall the server. Can anyone think of anything that would keep remote
users from registering with a new install? Is there some setting on the
server that I neglected to turn back on?
Bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:5E55FAA1-601D-4DED-8E5C-0324E2ED46B6@.microsoft.com...
> Hi Bob
> "Bob Bartel" wrote:
>> I am trying to reregister an existing server that we've been able to
>> register previously.
>> I can successfully register it inside the network, i.e., from another
>> workstation on the network, but when I try to register via a gateway,
>> i.e.,
>> over the internet I can't. I can ping the server, and the router has
>> port
>> forwarding setup correctly (port 1433), I've turned off the firewall,
>> and
>> nothing else has changed that I am aware of, but it just won't respond.
>> I
>> am confident that the SA password is correct.
>> I'm stumped. I have remote users who need to access this server, but
>> can't
>> get in.
>> Can anyone give me any suggestions. I've tried everything I can imagine.
>> The one change on this system is that we had to reinstall the Server, and
>> we've installed CA Antivirus. But I've uninstalled the CA firewall
>> software, and turned off the Windows Firewall (just to get this up...we
>> had
>> it running before with SQL traffic allowed).
>> Any Ideas are welcome!!
>> Bob
> It would be safer to use a VPN for this rather than leaving the server
> open.
> http://support.microsoft.com/kb/287932 describes the communication between
> the client and server, make sure you are using TCP/IP protcols and the
> client
> is not blocking the returning traffic. If you have set up this correctly
> you
> should be in-undated with people trying to hack in.
> John|||Hi
"Bob Bartel" wrote:
> As I mentioned, I have already had this working before. And only shut down
> my firewall for this test. I agree a VPN is a good choice and I'll probably
> turn it on, but...
> But the real problem is that even with the router correctly forwarding 1433
> and the firewall configured to allow the traffic, I can't register the
> server remotely.
> The only thing I can think of that may be effecting it is that I had to
> reinstall the server. Can anyone think of anything that would keep remote
> users from registering with a new install? Is there some setting on the
> server that I neglected to turn back on?
> Bob
>
If this is SQL Express you may not have turned on remote access. If this is
a named instance then it would not be using the default ports.
John|||Its a named instance...where to I specify the port?
bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:1B0EB2A5-8E12-41C2-9D87-5C38176D1783@.microsoft.com...
> Hi
> "Bob Bartel" wrote:
>> As I mentioned, I have already had this working before. And only shut
>> down
>> my firewall for this test. I agree a VPN is a good choice and I'll
>> probably
>> turn it on, but...
>> But the real problem is that even with the router correctly forwarding
>> 1433
>> and the firewall configured to allow the traffic, I can't register the
>> server remotely.
>> The only thing I can think of that may be effecting it is that I had to
>> reinstall the server. Can anyone think of anything that would keep
>> remote
>> users from registering with a new install? Is there some setting on the
>> server that I neglected to turn back on?
>> Bob
>>
> If this is SQL Express you may not have turned on remote access. If this
> is
> a named instance then it would not be using the default ports.
> John|||Hi Bob
"Bob Bartel" wrote:
> Its a named instance...where to I specify the port?
> bob
In the SQL Server Configuration manager there will be an entry in the SQL
Server 2005 Network Configuration branch for your instance. This will shows
which protocols are installed and enabled. Right clicking TCP/IP and choosing
properties and on the IP Address tab you can set the protocol to be enabled
and also set the port. You will need to make sure that there are no other
instances using this port.
John
Problem Registering Existing Server
register previously.
I can successfully register it inside the network, i.e., from another
workstation on the network, but when I try to register via a gateway, i.e.,
over the internet I can't. I can ping the server, and the router has port
forwarding setup correctly (port 1433), I've turned off the firewall, and
nothing else has changed that I am aware of, but it just won't respond. I
am confident that the SA password is correct.
I'm stumped. I have remote users who need to access this server, but can't
get in.
Can anyone give me any suggestions. I've tried everything I can imagine.
The one change on this system is that we had to reinstall the Server, and
we've installed CA Antivirus. But I've uninstalled the CA firewall
software, and turned off the Windows Firewall (just to get this up...we had
it running before with SQL traffic allowed).
Any Ideas are welcome!!
BobHi Bob
"Bob Bartel" wrote:
> I am trying to reregister an existing server that we've been able to
> register previously.
> I can successfully register it inside the network, i.e., from another
> workstation on the network, but when I try to register via a gateway, i.e.
,
> over the internet I can't. I can ping the server, and the router has port
> forwarding setup correctly (port 1433), I've turned off the firewall, and
> nothing else has changed that I am aware of, but it just won't respond. I
> am confident that the SA password is correct.
> I'm stumped. I have remote users who need to access this server, but can'
t
> get in.
> Can anyone give me any suggestions. I've tried everything I can imagine.
> The one change on this system is that we had to reinstall the Server, and
> we've installed CA Antivirus. But I've uninstalled the CA firewall
> software, and turned off the Windows Firewall (just to get this up...we ha
d
> it running before with SQL traffic allowed).
> Any Ideas are welcome!!
> Bob
>
It would be safer to use a VPN for this rather than leaving the server open.
http://support.microsoft.com/kb/287932 describes the communication between
the client and server, make sure you are using TCP/IP protcols and the clien
t
is not blocking the returning traffic. If you have set up this correctly you
should be in-undated with people trying to hack in.
John|||As I mentioned, I have already had this working before. And only shut down
my firewall for this test. I agree a VPN is a good choice and I'll probably
turn it on, but...
But the real problem is that even with the router correctly forwarding 1433
and the firewall configured to allow the traffic, I can't register the
server remotely.
The only thing I can think of that may be effecting it is that I had to
reinstall the server. Can anyone think of anything that would keep remote
users from registering with a new install? Is there some setting on the
server that I neglected to turn back on?
Bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:5E55FAA1-601D-4DED-8E5C-0324E2ED46B6@.microsoft.com...
> Hi Bob
> "Bob Bartel" wrote:
>
> It would be safer to use a VPN for this rather than leaving the server
> open.
> http://support.microsoft.com/kb/287932 describes the communication between
> the client and server, make sure you are using TCP/IP protcols and the
> client
> is not blocking the returning traffic. If you have set up this correctly
> you
> should be in-undated with people trying to hack in.
> John|||Hi
"Bob Bartel" wrote:
> As I mentioned, I have already had this working before. And only shut dow
n
> my firewall for this test. I agree a VPN is a good choice and I'll probab
ly
> turn it on, but...
> But the real problem is that even with the router correctly forwarding 143
3
> and the firewall configured to allow the traffic, I can't register the
> server remotely.
> The only thing I can think of that may be effecting it is that I had to
> reinstall the server. Can anyone think of anything that would keep remote
> users from registering with a new install? Is there some setting on the
> server that I neglected to turn back on?
> Bob
>
If this is SQL Express you may not have turned on remote access. If this is
a named instance then it would not be using the default ports.
John|||Its a named instance...where to I specify the port?
bob
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:1B0EB2A5-8E12-41C2-9D87-5C38176D1783@.microsoft.com...
> Hi
> "Bob Bartel" wrote:
>
> If this is SQL Express you may not have turned on remote access. If this
> is
> a named instance then it would not be using the default ports.
> John|||Hi Bob
"Bob Bartel" wrote:
> Its a named instance...where to I specify the port?
> bob
In the SQL Server Configuration manager there will be an entry in the SQL
Server 2005 Network Configuration branch for your instance. This will shows
which protocols are installed and enabled. Right clicking TCP/IP and choosin
g
properties and on the IP Address tab you can set the protocol to be enabled
and also set the port. You will need to make sure that there are no other
instances using this port.
John
Friday, March 23, 2012
Problem Pulling From Access DB
We are currently moving existing SSIS packages from one server to another. The former server is 32 bit and the new server is 64 bit clustered (not sure if that's relevant or not, though).
One package in particular is giving me a headache. It pulls from an access file to sql server 2005 table. We set up the security as don't save senstive and put the connection strings in a config file. We had to set the original job up to run the package step under a proxy account to get it to work.
If we right click on the package through the SSIS Store interface and execute it runs fine. However when we try to run it through the scheduled job, it fails. I very much appears to be a permissions issue on the proxy account. The person setting up the server is somewhat new to the area of SQL Servers, so they cannot provide much feedback. We're very much in a tweak until it works position, unfortunately.
Here are the errors that I am getting, one from the history of the job, one from the SQL Server logging. Does anyone have a suggestion, and if it is a permissions issue, where to look? I've been at this for days, so I've tried several different approaches. It seems like right now that I almost got it to work, but it seems like the connection to the access db is failing. But if that's the case, why does it run fine through the proxy on the original server (using same account)? I guess that very well could come down to the 64 bit problem (saw this on some other posts). I should mention that I set up the package as Run64BitRuntime = false. Do I need to rethink this as a batch file using DTExec? That was actually our original solution on the former server, but we could never get to work.
Job History Error:
DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Cost_WorkDB" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed. End Error Error: 2007-03-23 16:19:14.92 Code: 0xC0047017 Source: Data Flow Task DTS.Pipeline Description: component "OLE DB Source" (1) failed validation and returned error code 0xC020801C. End Error Progress: 2007-03-23 16:19:14.92 Source: Data Flow Task Validating: 100% complete End Progress Error: 2007-03-23 16:19:14.94 Code: 0xC004700C Source: Data Flow Task DTS.Pipeline Description: One or more component failed validation. End Error Error: 2007-03-23 16:19:14.94 Code: 0xC0024107 Source: Data Flow Task Description: There were errors during task validation.... The package execution fa... The step failed.
sysdtslog90 error:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Cost_WorkDB" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
component "OLE DB Source" (1) failed validation and returned error code 0xC020801C.
OK I solved the problem myself. This was in fact a 32-bit vs. 64-bit problem, even though the lovely errors I was getting didn't even come close to explaing that to me. I provided a link below on how to run a package in a scheduled job that hits a Jet 4.0 connection (I think excel may have this problem also).
But, I hate when people simply do that (include link), so here's how I fixed it.
Create a new scheduled job.
Add a new step.
When you edit the step, the 'Type' will be "Operating System (cmdExec)"
You can use DtExecUI to create your command line step, but here is what I used exactly - quotation mark locations are VERY important. Also, I think you may need to have the complete call on one line:
\\Server\E$\Program Files\Microsoft SQL Server (x86)\90\DTS\Binn\DTExec.exe /DTS "\MSDB_ATC\PACKAGE_NAME" /SERVER "SERVER_NAME" /CONFIGFILE "\\Server\R$\\PACKAGE_CONFIG.dtsConfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EW
Edit command to match yours, and paste into job step edit.
Hope this helps someone, it took me DAYS to figure out.
http://msdn2.microsoft.com/en-us/library/ms141766.aspx
|||
thank you... It's realy helpful to me.
The following is my update list,
\\Server\E$\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe /DTS "\MSDB_ATC\PACKAGE_NAME" /SERVER "SERVER_NAME" /CONFIGFILE "\\Server\R$\\PACKAGE_CONFIG.dtsConfig" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF /REPORTING EW
|||Thanks Jay, this saved my day
Friday, March 9, 2012
problem linking tables
"
Error ODBC : [Microsoft][ODBC SQL Server Driver][SQL Server]Conflict between
instruction ALTER TABLE and the constraint COLUMN FOREIGN KEY
'FK_etablissement_delegation'. the conflit happened in database
'maintenance', table 'delegation', column 'id_dele'."
nb fields are identic and nonnulls.The table's field where you'd like to set a foreign key(table 'delegation', column 'id_dele') contains an ID that does not exist in the table's field where you'd like to set a PK.