We have some client software developed by 3rd party that is used internally
and requires use of our SQL server. We've had some problems with this
software in the past and the developers solution was to add the dbclient
login (used by the client software) to the dbo (owner) group of the SQL
master database. This is concerns me. Is there any reason that client
software should have full access to the SQL master database? We have many
other production databases in use on this server. I'm considering
installing a separate instance of SQL 2005 (their newest version uses SQL
2005, the version we're using now uses SQL 2000) so that they can have full
ownership access of the master database without having to worry about this
affecting other existing databases. Thanks for any advice.
RyanHi,
No need to have DBO role in Master database. Just verify the sp_who
contineously for some time and confirm the
application user connects to Master database (You could also use profiler).
Once you confirmed revove the dbo role for the application user from Master
database and see what happends.
If it is production I recommend you to do during a offtime during
weekends...
Thanks
Hari
SQL Server MVP
"Ryan" <Tyveil@.newsgroups.nospam> wrote in message
news:Obzny9huGHA.5044@.TK2MSFTNGP05.phx.gbl...
> We have some client software developed by 3rd party that is used
> internally and requires use of our SQL server. We've had some problems
> with this software in the past and the developers solution was to add the
> dbclient login (used by the client software) to the dbo (owner) group of
> the SQL master database. This is concerns me. Is there any reason that
> client software should have full access to the SQL master database? We
> have many other production databases in use on this server. I'm
> considering installing a separate instance of SQL 2005 (their newest
> version uses SQL 2005, the version we're using now uses SQL 2000) so that
> they can have full ownership access of the master database without having
> to worry about this affecting other existing databases. Thanks for any
> advice.
> Ryan
>|||> This is concerns me.
That seems like an unreasonable response on the part of a DBA.
Concerned is far too mild. I think terrified would be reasonable.
This sounds like a quick fix that avoided having to actually figure
out what the real problem is. It is not something that I would allow
even on a development server, and on production any auditor (if they
knew the first thing about SQL Server) would have a field day.
Perhaps if someone does the analysis to identify the actual
requirement a more reasonable solution can be found. Otherwise I
would say that running on a separate instance is probably the only
answer.
Roy Harvey
Beacon Falls, CT
On Mon, 7 Aug 2006 07:43:38 -0500, "Ryan" <Tyveil@.newsgroups.nospam>
wrote:
>We have some client software developed by 3rd party that is used internally
>and requires use of our SQL server. We've had some problems with this
>software in the past and the developers solution was to add the dbclient
>login (used by the client software) to the dbo (owner) group of the SQL
>master database. This is concerns me. Is there any reason that client
>software should have full access to the SQL master database? We have many
>other production databases in use on this server. I'm considering
>installing a separate instance of SQL 2005 (their newest version uses SQL
>2005, the version we're using now uses SQL 2000) so that they can have full
>ownership access of the master database without having to worry about this
>affecting other existing databases. Thanks for any advice.
>Ryan
>|||Roy Harvey wrote:
> That seems like an unreasonable response on the part of a DBA.
> Concerned is far too mild. I think terrified would be reasonable.
> This sounds like a quick fix that avoided having to actually figure
> out what the real problem is. It is not something that I would allow
> even on a development server, and on production any auditor (if they
> knew the first thing about SQL Server) would have a field day.
> Perhaps if someone does the analysis to identify the actual
> requirement a more reasonable solution can be found. Otherwise I
> would say that running on a separate instance is probably the only
> answer.
When in doubt, make everybody an admin, right? ;-)
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Showing posts with label developed. Show all posts
Showing posts with label developed. Show all posts
Friday, February 24, 2012
dbo.master database
We have some client software developed by 3rd party that is used internally
and requires use of our SQL server. We've had some problems with this
software in the past and the developers solution was to add the dbclient
login (used by the client software) to the dbo (owner) group of the SQL
master database. This is concerns me. Is there any reason that client
software should have full access to the SQL master database? We have many
other production databases in use on this server. I'm considering
installing a separate instance of SQL 2005 (their newest version uses SQL
2005, the version we're using now uses SQL 2000) so that they can have full
ownership access of the master database without having to worry about this
affecting other existing databases. Thanks for any advice.
RyanHi,
No need to have DBO role in Master database. Just verify the sp_who
contineously for some time and confirm the
application user connects to Master database (You could also use profiler).
Once you confirmed revove the dbo role for the application user from Master
database and see what happends.
If it is production I recommend you to do during a offtime during
weekends...
Thanks
Hari
SQL Server MVP
"Ryan" <Tyveil@.newsgroups.nospam> wrote in message
news:Obzny9huGHA.5044@.TK2MSFTNGP05.phx.gbl...
> We have some client software developed by 3rd party that is used
> internally and requires use of our SQL server. We've had some problems
> with this software in the past and the developers solution was to add the
> dbclient login (used by the client software) to the dbo (owner) group of
> the SQL master database. This is concerns me. Is there any reason that
> client software should have full access to the SQL master database? We
> have many other production databases in use on this server. I'm
> considering installing a separate instance of SQL 2005 (their newest
> version uses SQL 2005, the version we're using now uses SQL 2000) so that
> they can have full ownership access of the master database without having
> to worry about this affecting other existing databases. Thanks for any
> advice.
> Ryan
>|||> This is concerns me.
That seems like an unreasonable response on the part of a DBA.
Concerned is far too mild. I think terrified would be reasonable.
This sounds like a quick fix that avoided having to actually figure
out what the real problem is. It is not something that I would allow
even on a development server, and on production any auditor (if they
knew the first thing about SQL Server) would have a field day.
Perhaps if someone does the analysis to identify the actual
requirement a more reasonable solution can be found. Otherwise I
would say that running on a separate instance is probably the only
answer.
Roy Harvey
Beacon Falls, CT
On Mon, 7 Aug 2006 07:43:38 -0500, "Ryan" <Tyveil@.newsgroups.nospam>
wrote:
>We have some client software developed by 3rd party that is used internally
>and requires use of our SQL server. We've had some problems with this
>software in the past and the developers solution was to add the dbclient
>login (used by the client software) to the dbo (owner) group of the SQL
>master database. This is concerns me. Is there any reason that client
>software should have full access to the SQL master database? We have many
>other production databases in use on this server. I'm considering
>installing a separate instance of SQL 2005 (their newest version uses SQL
>2005, the version we're using now uses SQL 2000) so that they can have full
>ownership access of the master database without having to worry about this
>affecting other existing databases. Thanks for any advice.
>Ryan
>|||Roy Harvey wrote:
>> This is concerns me.
> That seems like an unreasonable response on the part of a DBA.
> Concerned is far too mild. I think terrified would be reasonable.
> This sounds like a quick fix that avoided having to actually figure
> out what the real problem is. It is not something that I would allow
> even on a development server, and on production any auditor (if they
> knew the first thing about SQL Server) would have a field day.
> Perhaps if someone does the analysis to identify the actual
> requirement a more reasonable solution can be found. Otherwise I
> would say that running on a separate instance is probably the only
> answer.
When in doubt, make everybody an admin, right? ;-)
Tracy McKibben
MCDBA
http://www.realsqlguy.com
and requires use of our SQL server. We've had some problems with this
software in the past and the developers solution was to add the dbclient
login (used by the client software) to the dbo (owner) group of the SQL
master database. This is concerns me. Is there any reason that client
software should have full access to the SQL master database? We have many
other production databases in use on this server. I'm considering
installing a separate instance of SQL 2005 (their newest version uses SQL
2005, the version we're using now uses SQL 2000) so that they can have full
ownership access of the master database without having to worry about this
affecting other existing databases. Thanks for any advice.
RyanHi,
No need to have DBO role in Master database. Just verify the sp_who
contineously for some time and confirm the
application user connects to Master database (You could also use profiler).
Once you confirmed revove the dbo role for the application user from Master
database and see what happends.
If it is production I recommend you to do during a offtime during
weekends...
Thanks
Hari
SQL Server MVP
"Ryan" <Tyveil@.newsgroups.nospam> wrote in message
news:Obzny9huGHA.5044@.TK2MSFTNGP05.phx.gbl...
> We have some client software developed by 3rd party that is used
> internally and requires use of our SQL server. We've had some problems
> with this software in the past and the developers solution was to add the
> dbclient login (used by the client software) to the dbo (owner) group of
> the SQL master database. This is concerns me. Is there any reason that
> client software should have full access to the SQL master database? We
> have many other production databases in use on this server. I'm
> considering installing a separate instance of SQL 2005 (their newest
> version uses SQL 2005, the version we're using now uses SQL 2000) so that
> they can have full ownership access of the master database without having
> to worry about this affecting other existing databases. Thanks for any
> advice.
> Ryan
>|||> This is concerns me.
That seems like an unreasonable response on the part of a DBA.
Concerned is far too mild. I think terrified would be reasonable.
This sounds like a quick fix that avoided having to actually figure
out what the real problem is. It is not something that I would allow
even on a development server, and on production any auditor (if they
knew the first thing about SQL Server) would have a field day.
Perhaps if someone does the analysis to identify the actual
requirement a more reasonable solution can be found. Otherwise I
would say that running on a separate instance is probably the only
answer.
Roy Harvey
Beacon Falls, CT
On Mon, 7 Aug 2006 07:43:38 -0500, "Ryan" <Tyveil@.newsgroups.nospam>
wrote:
>We have some client software developed by 3rd party that is used internally
>and requires use of our SQL server. We've had some problems with this
>software in the past and the developers solution was to add the dbclient
>login (used by the client software) to the dbo (owner) group of the SQL
>master database. This is concerns me. Is there any reason that client
>software should have full access to the SQL master database? We have many
>other production databases in use on this server. I'm considering
>installing a separate instance of SQL 2005 (their newest version uses SQL
>2005, the version we're using now uses SQL 2000) so that they can have full
>ownership access of the master database without having to worry about this
>affecting other existing databases. Thanks for any advice.
>Ryan
>|||Roy Harvey wrote:
>> This is concerns me.
> That seems like an unreasonable response on the part of a DBA.
> Concerned is far too mild. I think terrified would be reasonable.
> This sounds like a quick fix that avoided having to actually figure
> out what the real problem is. It is not something that I would allow
> even on a development server, and on production any auditor (if they
> knew the first thing about SQL Server) would have a field day.
> Perhaps if someone does the analysis to identify the actual
> requirement a more reasonable solution can be found. Otherwise I
> would say that running on a separate instance is probably the only
> answer.
When in doubt, make everybody an admin, right? ;-)
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Tuesday, February 14, 2012
DBLIB
Hello!
I have developed a software which uses DBLib to access SQLServer 2000.
I tried if the same software will work with 32 bit version of SQLServer
2005 - there was no problem.
But now I have a customer who has a 64 bit version of SQLServer 2005 and I
urgently need to find solution for using the same software with 64 bit
version of SQLServer 2005.
Do I need a 64 bit ntwdblib.dll?
Has Microsoft implemented a 64 bit version of DBLib?
Thank you!Hi
DBLib is in "Maintenance mode" since SQL Server 7.0. No new functionality is
supplied.
DBLib is not supported on 64 bit, either x64 or IA64.
It is very old technology. Any reason you did not use OLE DB to develop
against?
Regards
--
Mike
This posting is provided "AS IS" with no warranties, and confers no rights.
"ggeshev" <ggeshev@.tonegan.bg> wrote in message
news:O%23fTxr3yGHA.3360@.TK2MSFTNGP03.phx.gbl...
> Hello!
> I have developed a software which uses DBLib to access SQLServer 2000.
> I tried if the same software will work with 32 bit version of SQLServer
> 2005 - there was no problem.
> But now I have a customer who has a 64 bit version of SQLServer 2005 and I
> urgently need to find solution for using the same software with 64 bit
> version of SQLServer 2005.
> Do I need a 64 bit ntwdblib.dll?
> Has Microsoft implemented a 64 bit version of DBLib?
> Thank you!
>|||Michael is right, DB-Lib is not supported on any 64-bit edition.
Here's what it says in Books Online in the topic "Deprecated Database Engine
Features in SQL Server 2005
"Although the SQL Server 2005 Database Engine still supports connections
from existing applications using the DB-Library and Embedded SQL APIs, it
does not include the files or documentation needed to do programming work on
applications that use these APIs. A future version of the SQL Server
Database Engine will drop support for connections from DB-Library or
Embedded SQL applications. Do not use DB-Library or Embedded SQL to develop
new applications. Remove any dependencies on either DB-Library or Embedded
SQL when modifying existing applications. Instead of these APIs, use the
SQLClient namespace or an API such as OLE DB or ODBC. SQL Server 2005 does
not include the DB-Library DLL required to run these applications. To run
DB-Library or Embedded SQL applications you must have available the
DB-Library DLL from SQL Server version 6.5, SQL Server 7.0, or SQL Server
2000."
Gail Erickson [MS]
SQL Server Documentation Team
This posting is provided "AS IS" with no warranties, and confers no rights
Download the latest version of Books Online from
http://www.microsoft.com/technet/pr...oads/books.mspx
"Michael Epprecht [MSFT]" <michael.epprecht@.online.microsoft.com> wrote
in
message news:%23EBDk%233yGHA.4104@.TK2MSFTNGP02.phx.gbl...
> Hi
> DBLib is in "Maintenance mode" since SQL Server 7.0. No new functionality
> is supplied.
> DBLib is not supported on 64 bit, either x64 or IA64.
> It is very old technology. Any reason you did not use OLE DB to develop
> against?
> Regards
> --
> Mike
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "ggeshev" <ggeshev@.tonegan.bg> wrote in message
> news:O%23fTxr3yGHA.3360@.TK2MSFTNGP03.phx.gbl...
>
I have developed a software which uses DBLib to access SQLServer 2000.
I tried if the same software will work with 32 bit version of SQLServer
2005 - there was no problem.
But now I have a customer who has a 64 bit version of SQLServer 2005 and I
urgently need to find solution for using the same software with 64 bit
version of SQLServer 2005.
Do I need a 64 bit ntwdblib.dll?
Has Microsoft implemented a 64 bit version of DBLib?
Thank you!Hi
DBLib is in "Maintenance mode" since SQL Server 7.0. No new functionality is
supplied.
DBLib is not supported on 64 bit, either x64 or IA64.
It is very old technology. Any reason you did not use OLE DB to develop
against?
Regards
--
Mike
This posting is provided "AS IS" with no warranties, and confers no rights.
"ggeshev" <ggeshev@.tonegan.bg> wrote in message
news:O%23fTxr3yGHA.3360@.TK2MSFTNGP03.phx.gbl...
> Hello!
> I have developed a software which uses DBLib to access SQLServer 2000.
> I tried if the same software will work with 32 bit version of SQLServer
> 2005 - there was no problem.
> But now I have a customer who has a 64 bit version of SQLServer 2005 and I
> urgently need to find solution for using the same software with 64 bit
> version of SQLServer 2005.
> Do I need a 64 bit ntwdblib.dll?
> Has Microsoft implemented a 64 bit version of DBLib?
> Thank you!
>|||Michael is right, DB-Lib is not supported on any 64-bit edition.
Here's what it says in Books Online in the topic "Deprecated Database Engine
Features in SQL Server 2005
"Although the SQL Server 2005 Database Engine still supports connections
from existing applications using the DB-Library and Embedded SQL APIs, it
does not include the files or documentation needed to do programming work on
applications that use these APIs. A future version of the SQL Server
Database Engine will drop support for connections from DB-Library or
Embedded SQL applications. Do not use DB-Library or Embedded SQL to develop
new applications. Remove any dependencies on either DB-Library or Embedded
SQL when modifying existing applications. Instead of these APIs, use the
SQLClient namespace or an API such as OLE DB or ODBC. SQL Server 2005 does
not include the DB-Library DLL required to run these applications. To run
DB-Library or Embedded SQL applications you must have available the
DB-Library DLL from SQL Server version 6.5, SQL Server 7.0, or SQL Server
2000."
Gail Erickson [MS]
SQL Server Documentation Team
This posting is provided "AS IS" with no warranties, and confers no rights
Download the latest version of Books Online from
http://www.microsoft.com/technet/pr...oads/books.mspx
"Michael Epprecht [MSFT]" <michael.epprecht@.online.microsoft.com> wrote
in
message news:%23EBDk%233yGHA.4104@.TK2MSFTNGP02.phx.gbl...
> Hi
> DBLib is in "Maintenance mode" since SQL Server 7.0. No new functionality
> is supplied.
> DBLib is not supported on 64 bit, either x64 or IA64.
> It is very old technology. Any reason you did not use OLE DB to develop
> against?
> Regards
> --
> Mike
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "ggeshev" <ggeshev@.tonegan.bg> wrote in message
> news:O%23fTxr3yGHA.3360@.TK2MSFTNGP03.phx.gbl...
>
Subscribe to:
Posts (Atom)