A Few Questions
Brian Donahue
Posts: 6,590 Bronze 1
Hi Derek,
Thanks for your question. You should be able to connect as normal to an
SQL server over the Internet using SQL compare, provided you supply the
fully-qualified name of the server or IP address, and you're not blocked by
a firewall on SQL Server's TCP port (1433, by default).
You could also email workspaces back and forth like you say. I think it
would be much neater to connect remotely, but network response times might
become a problem that way. Try both and see which works best for you.
The toolkit would be benificial to you if you wanted to automate
comparisons, or have them run at a certain time each day. I suppose you'd
have to rationalize a toolkit purchase by comparing the time you would save
manually running SQL comparisons versus the development time involved with
writing your own application.
Good luck with the project!
Regards,
Brian Donahue
Technical Support Engineer
Red Gate Software Ltd.
T: +44 870 1600 037
E: mailto:brian.donahue@red-gate.com
"Derek Hart" <dmhart@gte.net> wrote in message
news:AhF2Ko8rCHA.1156@server53...
> I have a SQL Server 2000 database that I will be shipping at different
times
> to different clients. I am thinking about using SQL Compare to do this.
For
> most of the clients, I can connect through a Virtual Private Network
> directly to their SQL Server, do the compare, and make the changes. For
> others that do not want me to connect that way, I wonder if there is a way
> to connect to their SQL Server through the Internet. (1) Is there such a
way
> to connect?
>
> If there is not a way to connect other than a VPN, I suspect the client
must
> script their database and email me the script. Then I recreate that script
> on my PC, and "SQL Compare" it to the latest development version. Then I
> would create an osql script and email it back to the client to do the
> upgrade. (2) Am I on the right track, or is there a better way to
automate
> this, maybe with the Red Gate SQL Toolkit, or should I use Visual
SourceSafe
> to track the different clients' versions?
>
> I would appreciate detailed answers to these questions, as I will be
making
> a decision that involves several developers on a very large project that
> will last about 2-3 years.
>
> Thank You,
>
> Derek Hart
>
>
Thanks for your question. You should be able to connect as normal to an
SQL server over the Internet using SQL compare, provided you supply the
fully-qualified name of the server or IP address, and you're not blocked by
a firewall on SQL Server's TCP port (1433, by default).
You could also email workspaces back and forth like you say. I think it
would be much neater to connect remotely, but network response times might
become a problem that way. Try both and see which works best for you.
The toolkit would be benificial to you if you wanted to automate
comparisons, or have them run at a certain time each day. I suppose you'd
have to rationalize a toolkit purchase by comparing the time you would save
manually running SQL comparisons versus the development time involved with
writing your own application.
Good luck with the project!
Regards,
Brian Donahue
Technical Support Engineer
Red Gate Software Ltd.
T: +44 870 1600 037
E: mailto:brian.donahue@red-gate.com
"Derek Hart" <dmhart@gte.net> wrote in message
news:AhF2Ko8rCHA.1156@server53...
> I have a SQL Server 2000 database that I will be shipping at different
times
> to different clients. I am thinking about using SQL Compare to do this.
For
> most of the clients, I can connect through a Virtual Private Network
> directly to their SQL Server, do the compare, and make the changes. For
> others that do not want me to connect that way, I wonder if there is a way
> to connect to their SQL Server through the Internet. (1) Is there such a
way
> to connect?
>
> If there is not a way to connect other than a VPN, I suspect the client
must
> script their database and email me the script. Then I recreate that script
> on my PC, and "SQL Compare" it to the latest development version. Then I
> would create an osql script and email it back to the client to do the
> upgrade. (2) Am I on the right track, or is there a better way to
automate
> this, maybe with the Red Gate SQL Toolkit, or should I use Visual
SourceSafe
> to track the different clients' versions?
>
> I would appreciate detailed answers to these questions, as I will be
making
> a decision that involves several developers on a very large project that
> will last about 2-3 years.
>
> Thank You,
>
> Derek Hart
>
>
This discussion has been closed.
Comments
Security is a big, big topic... You should be acceptably safe as long as
you've got SQL service pack 3. The Blaster worm was the last big threat to
SQL servers, but I haven't seen anything like that come around again since.
Kind Regards,
Brian Donahue
Red Gate Technical Support
"Erik" <x@x.nl> wrote in message news:a2ZqzJW8DHA.1556@server53...
> "Brian Donahue (Red Gate)" <brian.donahue@red-gate.com> wrote in message
> news:Gqea9lNsCHA.1156@server53...
> > Hi Derek,
> >
> > Thanks for your question. You should be able to connect as normal to
> an
> > SQL server over the Internet using SQL compare, provided you supply the
> > fully-qualified name of the server or IP address, and you're not blocked
> by
> > a firewall on SQL Server's TCP port (1433, by default).
> >
>
> As a new user of SQL Compare I have a question on this 'old' subject'.
>
> My clients server is behind a firewall. Would there be a security concern
to
> open port 1433 on the firewall, provided that both Windows 2000 Server and
> SQL Server 2000 are properly patched (through the Microsoft Windows Update
> Service)?
>
> Best regards,
>
> Erik
>
>