Greetings,
Have a transactional replication between 2 SQL 2000 servers. 1 is the publisher and the 2nd one is both distributor and subscriber.
Attempted to add an article to a publication via EM: right click the publication under 'Replication' folder and navigate to the
'Articles' tab. I 'showed' unpublished tables, check-marked the table I wanted added, got the warning screen about version compatibility, selected 'Apply' and then 'OK' to exit the properties page.
Of course the table does not appear in the subscriber db. I thought I followed what BOL said but I obviously missed something.
Anyone have any ideas as to what it was?
Thank you for your time.
Joe,
you need to run the snapshot agent to create the table snapshot, then run
the distribution agent to send it down.
Regards,
Paul Ibison
Showing posts with label greetings. Show all posts
Showing posts with label greetings. Show all posts
Sunday, February 19, 2012
Add Article To Trans Rep
Greetings again,
I am trying to add a table to a publication that already has a subscriber and have that table replicate to the subscriber.
2 servers, win2000, SQL 2000 all sp's applied.
1 server is the publisher and the 2nd is both the distributor and subscriber.
I went through the publication's properties page (em-replication-right click- properties) and added the table to the published articles list.
Then on the good advice of Paul Ibson in an earlier post to this newsgroup I created a new snapshot of the table and had
the dist. agent apply it. All went well.
However, new data in the table is not being replicated.
I've exhausted BOL and the web searches. Any recommendations as to the exact process I should follow would be greatly appreciated.
Thank you for your time.
Joe,
have you run the distribution agent? Run sp_browsereplcmds in the
distribution database to see if your new rows are waiting there. If they are
then just running the distribution agent will fix it. If not, then perhaps
the log reader is disabled?
HTH,
Paul Ibison
I am trying to add a table to a publication that already has a subscriber and have that table replicate to the subscriber.
2 servers, win2000, SQL 2000 all sp's applied.
1 server is the publisher and the 2nd is both the distributor and subscriber.
I went through the publication's properties page (em-replication-right click- properties) and added the table to the published articles list.
Then on the good advice of Paul Ibson in an earlier post to this newsgroup I created a new snapshot of the table and had
the dist. agent apply it. All went well.
However, new data in the table is not being replicated.
I've exhausted BOL and the web searches. Any recommendations as to the exact process I should follow would be greatly appreciated.
Thank you for your time.
Joe,
have you run the distribution agent? Run sp_browsereplcmds in the
distribution database to see if your new rows are waiting there. If they are
then just running the distribution agent will fix it. If not, then perhaps
the log reader is disabled?
HTH,
Paul Ibison
Thursday, February 9, 2012
Actual risk of opening port 1433
Greetings.
I have written a nice little application suite used by 8 or so workstations,
some of which are connected through a VPN. The IT people claim that port
1433 is blocked by default by Nortel's Conntivity VPN, and they will not
make an attempt to change it for fear it will muck up the works elsewhere.
As the SQL server (actually, an instance of MSDE) lives on a dedicated
little WinXP Pro box which does nothing else, I recommended they open port
1433 on their router and point it to that box, allowing the offsites to
circumvent the VPN altogether. The IT director looked at me point blank and
stated that would mean anyone could come in and "hack" both their Win2k
Server, and their IBM Midrange running OS/400.
My question - while I understand the director's concern is completely
irrational... what ACTUAL issues can opening port 1433 to an isolated box
really raise? Even assuming that the intruder coud bypass the credentials (I
am using SQL Authentication, gods help me), what could they possibly do to
anything other than that one MSDE instance?
Many thanks in advance.
Hal Meyer, Proprietor
the patchwerks
(423) 462-2606
http://www.thepatchwerks.com1. SQL Authentication is very insecure.
2. The 'box' is not isolated. It is connected to the network inside the
firewall.
3. Every hacker in the world knows that port 1433 is a standard SQL port and
therefore a target.
4. MSDE runs with LocalSystem permissions. That may provide a platform to
hack the inside servers.
5. Any hacker worth his/her 'salt' will know every weakness of MSDE -and
there a quite a few.
6. The IT people are right!
7. The IT director was very kind in his response to you.
So, suck it up and move on. There is unlikely to be any legitimate business
case for such a 'foolhardy' move.
Your outside users access the internal network using a secure VPN. That
'should' provide them access to the MSDE instance while connected through
the VPN. I would check with the VPN vendor about any problems accessing SQL
Server (MSDE) through the VPN 'tunnel'.
In the rare circumstances where there is a business case to open firewall
port 1433, it usually mandates Rules restricting external IP addresses, more
advanced security (SSL, etc.), as well as constant vigilence and traffic
logging - as well as a rigorous process to attempt to gain approval.
Think about leaving the door key to your home under the 'Welcome' mat. Would
that be a wise action? Wouldn't most potential thieves look under the mat as
their first effort to gain entry.
Arnie Rowland
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Hal Meyer" <hmeyer@.comcast.net> wrote in message
news:OK%23WxcvqGHA.1796@.TK2MSFTNGP03.phx.gbl...
> Greetings.
> I have written a nice little application suite used by 8 or so
> workstations, some of which are connected through a VPN. The IT people
> claim that port 1433 is blocked by default by Nortel's Conntivity VPN, and
> they will not make an attempt to change it for fear it will muck up the
> works elsewhere. As the SQL server (actually, an instance of MSDE) lives
> on a dedicated little WinXP Pro box which does nothing else, I recommended
> they open port 1433 on their router and point it to that box, allowing the
> offsites to circumvent the VPN altogether. The IT director looked at me
> point blank and stated that would mean anyone could come in and "hack"
> both their Win2k Server, and their IBM Midrange running OS/400.
> My question - while I understand the director's concern is completely
> irrational... what ACTUAL issues can opening port 1433 to an isolated box
> really raise? Even assuming that the intruder coud bypass the credentials
> (I am using SQL Authentication, gods help me), what could they possibly do
> to anything other than that one MSDE instance?
> Many thanks in advance.
> --
> Hal Meyer, Proprietor
> the patchwerks
> (423) 462-2606
> http://www.thepatchwerks.com
>
I have written a nice little application suite used by 8 or so workstations,
some of which are connected through a VPN. The IT people claim that port
1433 is blocked by default by Nortel's Conntivity VPN, and they will not
make an attempt to change it for fear it will muck up the works elsewhere.
As the SQL server (actually, an instance of MSDE) lives on a dedicated
little WinXP Pro box which does nothing else, I recommended they open port
1433 on their router and point it to that box, allowing the offsites to
circumvent the VPN altogether. The IT director looked at me point blank and
stated that would mean anyone could come in and "hack" both their Win2k
Server, and their IBM Midrange running OS/400.
My question - while I understand the director's concern is completely
irrational... what ACTUAL issues can opening port 1433 to an isolated box
really raise? Even assuming that the intruder coud bypass the credentials (I
am using SQL Authentication, gods help me), what could they possibly do to
anything other than that one MSDE instance?
Many thanks in advance.
Hal Meyer, Proprietor
the patchwerks
(423) 462-2606
http://www.thepatchwerks.com1. SQL Authentication is very insecure.
2. The 'box' is not isolated. It is connected to the network inside the
firewall.
3. Every hacker in the world knows that port 1433 is a standard SQL port and
therefore a target.
4. MSDE runs with LocalSystem permissions. That may provide a platform to
hack the inside servers.
5. Any hacker worth his/her 'salt' will know every weakness of MSDE -and
there a quite a few.
6. The IT people are right!
7. The IT director was very kind in his response to you.
So, suck it up and move on. There is unlikely to be any legitimate business
case for such a 'foolhardy' move.
Your outside users access the internal network using a secure VPN. That
'should' provide them access to the MSDE instance while connected through
the VPN. I would check with the VPN vendor about any problems accessing SQL
Server (MSDE) through the VPN 'tunnel'.
In the rare circumstances where there is a business case to open firewall
port 1433, it usually mandates Rules restricting external IP addresses, more
advanced security (SSL, etc.), as well as constant vigilence and traffic
logging - as well as a rigorous process to attempt to gain approval.
Think about leaving the door key to your home under the 'Welcome' mat. Would
that be a wise action? Wouldn't most potential thieves look under the mat as
their first effort to gain entry.
Arnie Rowland
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"Hal Meyer" <hmeyer@.comcast.net> wrote in message
news:OK%23WxcvqGHA.1796@.TK2MSFTNGP03.phx.gbl...
> Greetings.
> I have written a nice little application suite used by 8 or so
> workstations, some of which are connected through a VPN. The IT people
> claim that port 1433 is blocked by default by Nortel's Conntivity VPN, and
> they will not make an attempt to change it for fear it will muck up the
> works elsewhere. As the SQL server (actually, an instance of MSDE) lives
> on a dedicated little WinXP Pro box which does nothing else, I recommended
> they open port 1433 on their router and point it to that box, allowing the
> offsites to circumvent the VPN altogether. The IT director looked at me
> point blank and stated that would mean anyone could come in and "hack"
> both their Win2k Server, and their IBM Midrange running OS/400.
> My question - while I understand the director's concern is completely
> irrational... what ACTUAL issues can opening port 1433 to an isolated box
> really raise? Even assuming that the intruder coud bypass the credentials
> (I am using SQL Authentication, gods help me), what could they possibly do
> to anything other than that one MSDE instance?
> Many thanks in advance.
> --
> Hal Meyer, Proprietor
> the patchwerks
> (423) 462-2606
> http://www.thepatchwerks.com
>
Subscribe to:
Posts (Atom)