We were just purchased by another company who's exchange server has the same
name as our SQL server. Is there a best practice for renaming a SQL server?
Is there anything I should know prior to going down that road?Jason,
See question 29.
Frequently asked questions - SQL Server 2000 - Setup
http://support.microsoft.com/kb/257716
AMB
"Jason" wrote:
> We were just purchased by another company who's exchange server has the same
> name as our SQL server. Is there a best practice for renaming a SQL server?
> Is there anything I should know prior to going down that road?|||And also http://www.karaszi.com/SQLServer/info_change_server_name.asp .
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:99028D01-FB6D-4917-A2A6-D1D6E1C7BAE3@.microsoft.com...
> Jason,
> See question 29.
> Frequently asked questions - SQL Server 2000 - Setup
> http://support.microsoft.com/kb/257716
>
> AMB
> "Jason" wrote:
>> We were just purchased by another company who's exchange server has the same
>> name as our SQL server. Is there a best practice for renaming a SQL server?
>> Is there anything I should know prior to going down that road?
Showing posts with label company. Show all posts
Showing posts with label company. Show all posts
Friday, March 30, 2012
Tuesday, March 20, 2012
Removing User Right Assignments form SQL-Server Account
Hello everybody,
I'm currently securing a w2k box according to some recommendations
made by a company that audited our server.
Now among their recommendations is to remove the following rights from
the sql-server account. (The SQL Server runs under its own 'user
account' and in mixed mode)
According to them I should remove these permissions:
- Act as part of the Operating System
- Replace a process level token
- Increase quotas
- Log on as batch job
- Log on as service
I've browsed the web and found some documents, however none could
really answer which SQL-Features depend on these services.
Maybe someone in this forum has some experience or helpful urls.
Thanks very much.
the document:
SQL Server 2000 C2 Administrator's and User's Security Guide
at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/security/sqlc2.asp
somehow mentions that these four services are necessary, but not why.
* Act as part of the operating system.
* Increase quotas.
* Replace a process-level token.
* Log on as a service.Hallo Beat(e) M=FCller,
at first you must NOT REMOVE the right
- Log on as service (The sql-Server does not start anymore!)
second the others you may try but I do not suggest it. Please look at
http://www.microsoft.com/sql/techinfo/administration/2000/s
ecurity/securingsqlserver.asp
there are useful tipps to securing the sql-Server
- Log on as a batch job (removable depends on your Envoirement - !CHECK! does your sqlserver service use a start batch?)
- the others will be used for internal tuning and interaction - I you REALLY must to remove them try it on your on risk!
CU Ralf
I'm currently securing a w2k box according to some recommendations
made by a company that audited our server.
Now among their recommendations is to remove the following rights from
the sql-server account. (The SQL Server runs under its own 'user
account' and in mixed mode)
According to them I should remove these permissions:
- Act as part of the Operating System
- Replace a process level token
- Increase quotas
- Log on as batch job
- Log on as service
I've browsed the web and found some documents, however none could
really answer which SQL-Features depend on these services.
Maybe someone in this forum has some experience or helpful urls.
Thanks very much.
the document:
SQL Server 2000 C2 Administrator's and User's Security Guide
at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/security/sqlc2.asp
somehow mentions that these four services are necessary, but not why.
* Act as part of the operating system.
* Increase quotas.
* Replace a process-level token.
* Log on as a service.Hallo Beat(e) M=FCller,
at first you must NOT REMOVE the right
- Log on as service (The sql-Server does not start anymore!)
second the others you may try but I do not suggest it. Please look at
http://www.microsoft.com/sql/techinfo/administration/2000/s
ecurity/securingsqlserver.asp
there are useful tipps to securing the sql-Server
- Log on as a batch job (removable depends on your Envoirement - !CHECK! does your sqlserver service use a start batch?)
- the others will be used for internal tuning and interaction - I you REALLY must to remove them try it on your on risk!
CU Ralf
Friday, March 9, 2012
Removing Parameter Dependencies
I was wondering if anyone knows of a way to remove parameter dependencies.
I'm making a lot of reports for my company, but for some reason the Reports
Server is setting up a bunch of parameter dependencies, and it's causing
parameter entry to be extremely tedious (when you change a parameter that
another is dependent on, it'll reset the dependent parameter to its default
value).
So far the only way I've found is to manually edit the field in the report
server database - but I can't do that for all of the reports or ensure that
it'll stay updated in the future. Is there a way to edit parameter
dependencies?Any parameter which is used in a SQL statement will be re-evaluated often...
You can tell Reporting Services that it is NOT used in SQL by changing the
RDL...In SQL 2005 this will be an attribute in the dialog box...
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kyle" <Kyle@.discussions.microsoft.com> wrote in message
news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
>I was wondering if anyone knows of a way to remove parameter dependencies.
> I'm making a lot of reports for my company, but for some reason the
> Reports
> Server is setting up a bunch of parameter dependencies, and it's causing
> parameter entry to be extremely tedious (when you change a parameter that
> another is dependent on, it'll reset the dependent parameter to its
> default
> value).
> So far the only way I've found is to manually edit the field in the report
> server database - but I can't do that for all of the reports or ensure
> that
> it'll stay updated in the future. Is there a way to edit parameter
> dependencies?|||All of the parameters are used in the SQL, and we're not using 2005 (and
won't be in the near future).
I've noticed that the report server doesn't automatically set up parameter
dependencies when no default value is given for the parameter. However, as
we would like to have default values for our parameters, this doesn't help me
much.
Kyle
"Wayne Snyder" wrote:
> Any parameter which is used in a SQL statement will be re-evaluated often...
> You can tell Reporting Services that it is NOT used in SQL by changing the
> RDL...In SQL 2005 this will be an attribute in the dialog box...
> --
> Wayne Snyder MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> (Please respond only to the newsgroup.)
> I support the Professional Association for SQL Server ( PASS) and it's
> community of SQL Professionals.
> "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> >I was wondering if anyone knows of a way to remove parameter dependencies.
> > I'm making a lot of reports for my company, but for some reason the
> > Reports
> > Server is setting up a bunch of parameter dependencies, and it's causing
> > parameter entry to be extremely tedious (when you change a parameter that
> > another is dependent on, it'll reset the dependent parameter to its
> > default
> > value).
> >
> > So far the only way I've found is to manually edit the field in the report
> > server database - but I can't do that for all of the reports or ensure
> > that
> > it'll stay updated in the future. Is there a way to edit parameter
> > dependencies?
>
>|||Kyle,
I'm not sure what sort of defaults you are setting up, or if any of them are
dependant upon other parameters, but I ran into a similar situation, and here
is how I fixed it.
We have many reports where we wanted to display defalut dates (such as Date
From and Date To parameters being set to the first and last day of the
current month). If you set the parameter default using VB code as a
Non-Queried default value, it will assume that the parameter may be dependant
upon another parameter, and reevaluate the default whenever you edit
parameters before it. So, we created a dataset called DateParameters, and
used SQL to return two columns (BeginningOfMonth and EndOfMonth). For the
parameters, we set the default to "From Query" and used the columns of the
DateParameters data set to set the defaults. This prevented the parameters
as being labeled as dependant, and kept our reports from refreshing. If you
actually have defaults that are dependant upon other parameter values, you
can still use a dataset to do the computations, but your page will refresh
these parameters if their dependant values change.
Sorry this was so long-winded, but I hope it helps you.
David
"Kyle" wrote:
> All of the parameters are used in the SQL, and we're not using 2005 (and
> won't be in the near future).
> I've noticed that the report server doesn't automatically set up parameter
> dependencies when no default value is given for the parameter. However, as
> we would like to have default values for our parameters, this doesn't help me
> much.
> Kyle
> "Wayne Snyder" wrote:
> > Any parameter which is used in a SQL statement will be re-evaluated often...
> > You can tell Reporting Services that it is NOT used in SQL by changing the
> > RDL...In SQL 2005 this will be an attribute in the dialog box...
> >
> > --
> > Wayne Snyder MCDBA, SQL Server MVP
> > Mariner, Charlotte, NC
> > (Please respond only to the newsgroup.)
> >
> > I support the Professional Association for SQL Server ( PASS) and it's
> > community of SQL Professionals.
> > "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> > news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> > >I was wondering if anyone knows of a way to remove parameter dependencies.
> > > I'm making a lot of reports for my company, but for some reason the
> > > Reports
> > > Server is setting up a bunch of parameter dependencies, and it's causing
> > > parameter entry to be extremely tedious (when you change a parameter that
> > > another is dependent on, it'll reset the dependent parameter to its
> > > default
> > > value).
> > >
> > > So far the only way I've found is to manually edit the field in the report
> > > server database - but I can't do that for all of the reports or ensure
> > > that
> > > it'll stay updated in the future. Is there a way to edit parameter
> > > dependencies?
> >
> >
> >|||Thank you very much!
That solved almost every single problem I was having with parameters. Now
if I can just figure out how to get tooltips to display for the parameter
form boxes...
Thanks again!
Kyle
"David Siebert" wrote:
> Kyle,
> I'm not sure what sort of defaults you are setting up, or if any of them are
> dependant upon other parameters, but I ran into a similar situation, and here
> is how I fixed it.
> We have many reports where we wanted to display defalut dates (such as Date
> From and Date To parameters being set to the first and last day of the
> current month). If you set the parameter default using VB code as a
> Non-Queried default value, it will assume that the parameter may be dependant
> upon another parameter, and reevaluate the default whenever you edit
> parameters before it. So, we created a dataset called DateParameters, and
> used SQL to return two columns (BeginningOfMonth and EndOfMonth). For the
> parameters, we set the default to "From Query" and used the columns of the
> DateParameters data set to set the defaults. This prevented the parameters
> as being labeled as dependant, and kept our reports from refreshing. If you
> actually have defaults that are dependant upon other parameter values, you
> can still use a dataset to do the computations, but your page will refresh
> these parameters if their dependant values change.
> Sorry this was so long-winded, but I hope it helps you.
> David
> "Kyle" wrote:
> > All of the parameters are used in the SQL, and we're not using 2005 (and
> > won't be in the near future).
> >
> > I've noticed that the report server doesn't automatically set up parameter
> > dependencies when no default value is given for the parameter. However, as
> > we would like to have default values for our parameters, this doesn't help me
> > much.
> >
> > Kyle
> >
> > "Wayne Snyder" wrote:
> >
> > > Any parameter which is used in a SQL statement will be re-evaluated often...
> > > You can tell Reporting Services that it is NOT used in SQL by changing the
> > > RDL...In SQL 2005 this will be an attribute in the dialog box...
> > >
> > > --
> > > Wayne Snyder MCDBA, SQL Server MVP
> > > Mariner, Charlotte, NC
> > > (Please respond only to the newsgroup.)
> > >
> > > I support the Professional Association for SQL Server ( PASS) and it's
> > > community of SQL Professionals.
> > > "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> > > news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> > > >I was wondering if anyone knows of a way to remove parameter dependencies.
> > > > I'm making a lot of reports for my company, but for some reason the
> > > > Reports
> > > > Server is setting up a bunch of parameter dependencies, and it's causing
> > > > parameter entry to be extremely tedious (when you change a parameter that
> > > > another is dependent on, it'll reset the dependent parameter to its
> > > > default
> > > > value).
> > > >
> > > > So far the only way I've found is to manually edit the field in the report
> > > > server database - but I can't do that for all of the reports or ensure
> > > > that
> > > > it'll stay updated in the future. Is there a way to edit parameter
> > > > dependencies?
> > >
> > >
> > >
I'm making a lot of reports for my company, but for some reason the Reports
Server is setting up a bunch of parameter dependencies, and it's causing
parameter entry to be extremely tedious (when you change a parameter that
another is dependent on, it'll reset the dependent parameter to its default
value).
So far the only way I've found is to manually edit the field in the report
server database - but I can't do that for all of the reports or ensure that
it'll stay updated in the future. Is there a way to edit parameter
dependencies?Any parameter which is used in a SQL statement will be re-evaluated often...
You can tell Reporting Services that it is NOT used in SQL by changing the
RDL...In SQL 2005 this will be an attribute in the dialog box...
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kyle" <Kyle@.discussions.microsoft.com> wrote in message
news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
>I was wondering if anyone knows of a way to remove parameter dependencies.
> I'm making a lot of reports for my company, but for some reason the
> Reports
> Server is setting up a bunch of parameter dependencies, and it's causing
> parameter entry to be extremely tedious (when you change a parameter that
> another is dependent on, it'll reset the dependent parameter to its
> default
> value).
> So far the only way I've found is to manually edit the field in the report
> server database - but I can't do that for all of the reports or ensure
> that
> it'll stay updated in the future. Is there a way to edit parameter
> dependencies?|||All of the parameters are used in the SQL, and we're not using 2005 (and
won't be in the near future).
I've noticed that the report server doesn't automatically set up parameter
dependencies when no default value is given for the parameter. However, as
we would like to have default values for our parameters, this doesn't help me
much.
Kyle
"Wayne Snyder" wrote:
> Any parameter which is used in a SQL statement will be re-evaluated often...
> You can tell Reporting Services that it is NOT used in SQL by changing the
> RDL...In SQL 2005 this will be an attribute in the dialog box...
> --
> Wayne Snyder MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> (Please respond only to the newsgroup.)
> I support the Professional Association for SQL Server ( PASS) and it's
> community of SQL Professionals.
> "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> >I was wondering if anyone knows of a way to remove parameter dependencies.
> > I'm making a lot of reports for my company, but for some reason the
> > Reports
> > Server is setting up a bunch of parameter dependencies, and it's causing
> > parameter entry to be extremely tedious (when you change a parameter that
> > another is dependent on, it'll reset the dependent parameter to its
> > default
> > value).
> >
> > So far the only way I've found is to manually edit the field in the report
> > server database - but I can't do that for all of the reports or ensure
> > that
> > it'll stay updated in the future. Is there a way to edit parameter
> > dependencies?
>
>|||Kyle,
I'm not sure what sort of defaults you are setting up, or if any of them are
dependant upon other parameters, but I ran into a similar situation, and here
is how I fixed it.
We have many reports where we wanted to display defalut dates (such as Date
From and Date To parameters being set to the first and last day of the
current month). If you set the parameter default using VB code as a
Non-Queried default value, it will assume that the parameter may be dependant
upon another parameter, and reevaluate the default whenever you edit
parameters before it. So, we created a dataset called DateParameters, and
used SQL to return two columns (BeginningOfMonth and EndOfMonth). For the
parameters, we set the default to "From Query" and used the columns of the
DateParameters data set to set the defaults. This prevented the parameters
as being labeled as dependant, and kept our reports from refreshing. If you
actually have defaults that are dependant upon other parameter values, you
can still use a dataset to do the computations, but your page will refresh
these parameters if their dependant values change.
Sorry this was so long-winded, but I hope it helps you.
David
"Kyle" wrote:
> All of the parameters are used in the SQL, and we're not using 2005 (and
> won't be in the near future).
> I've noticed that the report server doesn't automatically set up parameter
> dependencies when no default value is given for the parameter. However, as
> we would like to have default values for our parameters, this doesn't help me
> much.
> Kyle
> "Wayne Snyder" wrote:
> > Any parameter which is used in a SQL statement will be re-evaluated often...
> > You can tell Reporting Services that it is NOT used in SQL by changing the
> > RDL...In SQL 2005 this will be an attribute in the dialog box...
> >
> > --
> > Wayne Snyder MCDBA, SQL Server MVP
> > Mariner, Charlotte, NC
> > (Please respond only to the newsgroup.)
> >
> > I support the Professional Association for SQL Server ( PASS) and it's
> > community of SQL Professionals.
> > "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> > news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> > >I was wondering if anyone knows of a way to remove parameter dependencies.
> > > I'm making a lot of reports for my company, but for some reason the
> > > Reports
> > > Server is setting up a bunch of parameter dependencies, and it's causing
> > > parameter entry to be extremely tedious (when you change a parameter that
> > > another is dependent on, it'll reset the dependent parameter to its
> > > default
> > > value).
> > >
> > > So far the only way I've found is to manually edit the field in the report
> > > server database - but I can't do that for all of the reports or ensure
> > > that
> > > it'll stay updated in the future. Is there a way to edit parameter
> > > dependencies?
> >
> >
> >|||Thank you very much!
That solved almost every single problem I was having with parameters. Now
if I can just figure out how to get tooltips to display for the parameter
form boxes...
Thanks again!
Kyle
"David Siebert" wrote:
> Kyle,
> I'm not sure what sort of defaults you are setting up, or if any of them are
> dependant upon other parameters, but I ran into a similar situation, and here
> is how I fixed it.
> We have many reports where we wanted to display defalut dates (such as Date
> From and Date To parameters being set to the first and last day of the
> current month). If you set the parameter default using VB code as a
> Non-Queried default value, it will assume that the parameter may be dependant
> upon another parameter, and reevaluate the default whenever you edit
> parameters before it. So, we created a dataset called DateParameters, and
> used SQL to return two columns (BeginningOfMonth and EndOfMonth). For the
> parameters, we set the default to "From Query" and used the columns of the
> DateParameters data set to set the defaults. This prevented the parameters
> as being labeled as dependant, and kept our reports from refreshing. If you
> actually have defaults that are dependant upon other parameter values, you
> can still use a dataset to do the computations, but your page will refresh
> these parameters if their dependant values change.
> Sorry this was so long-winded, but I hope it helps you.
> David
> "Kyle" wrote:
> > All of the parameters are used in the SQL, and we're not using 2005 (and
> > won't be in the near future).
> >
> > I've noticed that the report server doesn't automatically set up parameter
> > dependencies when no default value is given for the parameter. However, as
> > we would like to have default values for our parameters, this doesn't help me
> > much.
> >
> > Kyle
> >
> > "Wayne Snyder" wrote:
> >
> > > Any parameter which is used in a SQL statement will be re-evaluated often...
> > > You can tell Reporting Services that it is NOT used in SQL by changing the
> > > RDL...In SQL 2005 this will be an attribute in the dialog box...
> > >
> > > --
> > > Wayne Snyder MCDBA, SQL Server MVP
> > > Mariner, Charlotte, NC
> > > (Please respond only to the newsgroup.)
> > >
> > > I support the Professional Association for SQL Server ( PASS) and it's
> > > community of SQL Professionals.
> > > "Kyle" <Kyle@.discussions.microsoft.com> wrote in message
> > > news:B619A389-EB95-4DE8-AE05-5E46BB1A4208@.microsoft.com...
> > > >I was wondering if anyone knows of a way to remove parameter dependencies.
> > > > I'm making a lot of reports for my company, but for some reason the
> > > > Reports
> > > > Server is setting up a bunch of parameter dependencies, and it's causing
> > > > parameter entry to be extremely tedious (when you change a parameter that
> > > > another is dependent on, it'll reset the dependent parameter to its
> > > > default
> > > > value).
> > > >
> > > > So far the only way I've found is to manually edit the field in the report
> > > > server database - but I can't do that for all of the reports or ensure
> > > > that
> > > > it'll stay updated in the future. Is there a way to edit parameter
> > > > dependencies?
> > >
> > >
> > >
Removing Old Databases
My company will soon be upgrading our Access Database to SQL Server 2000. In
order to begin testing and programming for the move, I have downloaded and
installed SQL2K MSDE SP3. My install went smooth and it works fine. The
problem I am having is when I am creating new databases or upgrading from
Access databases. If I decide the SQL Database that I created isn't what I
am needing then I go to the Data directory for MSDE and delete the database.
However, when I use Access to create another database by upsizing it sees
that the previous databases are still installed, as does the MSDE Manager
that I downloaded.
Question is, is there something else that I need to be doing to completely
remove the SQL databases from my system beyond deleting them from the Data
folder wherer they are initially created?
Thanks in advance.
If you mean remove the database, while keep the server (SQL Server/MSDE),
then you need detach the database from SQL Server/MSDE first. Then you can
delete the corresponding *.mdf/*.ldf files.
"digger27" <digger27@.discussions.microsoft.com> wrote in message
news:914CC09F-1341-427B-A6EC-52C4C6FCC191@.microsoft.com...
> My company will soon be upgrading our Access Database to SQL Server 2000.
In
> order to begin testing and programming for the move, I have downloaded and
> installed SQL2K MSDE SP3. My install went smooth and it works fine. The
> problem I am having is when I am creating new databases or upgrading from
> Access databases. If I decide the SQL Database that I created isn't what
I
> am needing then I go to the Data directory for MSDE and delete the
database.
> However, when I use Access to create another database by upsizing it sees
> that the previous databases are still installed, as does the MSDE Manager
> that I downloaded.
> Question is, is there something else that I need to be doing to completely
> remove the SQL databases from my system beyond deleting them from the Data
> folder wherer they are initially created?
> Thanks in advance.
|||Norman,
That was exactly the problem. Everything works great now.
"Norman Yuan" wrote:
> If you mean remove the database, while keep the server (SQL Server/MSDE),
> then you need detach the database from SQL Server/MSDE first. Then you can
> delete the corresponding *.mdf/*.ldf files.
> "digger27" <digger27@.discussions.microsoft.com> wrote in message
> news:914CC09F-1341-427B-A6EC-52C4C6FCC191@.microsoft.com...
> In
> I
> database.
>
>
order to begin testing and programming for the move, I have downloaded and
installed SQL2K MSDE SP3. My install went smooth and it works fine. The
problem I am having is when I am creating new databases or upgrading from
Access databases. If I decide the SQL Database that I created isn't what I
am needing then I go to the Data directory for MSDE and delete the database.
However, when I use Access to create another database by upsizing it sees
that the previous databases are still installed, as does the MSDE Manager
that I downloaded.
Question is, is there something else that I need to be doing to completely
remove the SQL databases from my system beyond deleting them from the Data
folder wherer they are initially created?
Thanks in advance.
If you mean remove the database, while keep the server (SQL Server/MSDE),
then you need detach the database from SQL Server/MSDE first. Then you can
delete the corresponding *.mdf/*.ldf files.
"digger27" <digger27@.discussions.microsoft.com> wrote in message
news:914CC09F-1341-427B-A6EC-52C4C6FCC191@.microsoft.com...
> My company will soon be upgrading our Access Database to SQL Server 2000.
In
> order to begin testing and programming for the move, I have downloaded and
> installed SQL2K MSDE SP3. My install went smooth and it works fine. The
> problem I am having is when I am creating new databases or upgrading from
> Access databases. If I decide the SQL Database that I created isn't what
I
> am needing then I go to the Data directory for MSDE and delete the
database.
> However, when I use Access to create another database by upsizing it sees
> that the previous databases are still installed, as does the MSDE Manager
> that I downloaded.
> Question is, is there something else that I need to be doing to completely
> remove the SQL databases from my system beyond deleting them from the Data
> folder wherer they are initially created?
> Thanks in advance.
|||Norman,
That was exactly the problem. Everything works great now.
"Norman Yuan" wrote:
> If you mean remove the database, while keep the server (SQL Server/MSDE),
> then you need detach the database from SQL Server/MSDE first. Then you can
> delete the corresponding *.mdf/*.ldf files.
> "digger27" <digger27@.discussions.microsoft.com> wrote in message
> news:914CC09F-1341-427B-A6EC-52C4C6FCC191@.microsoft.com...
> In
> I
> database.
>
>
Subscribe to:
Posts (Atom)