Database became suspect while logshipping and adding a datafile

Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......
Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......

Database became suspect while logshipping and adding a datafile

Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......|||Thanks for your help. Is not there a way of saving the database before making
a full
restore?
"Mark Allison" wrote:
> Erdinc,
> Do a full backup on the primary server and restore that over your DR.
> Make sure your path names are the same. Then continue as normal.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Erdinc the logshipping man wrote:
> > Hello,
> >
> > We do loshipping between two servers. Our database in primary server
> > grew, so we had to add a datafile to the primary database. However, we missed
> > a point. The directory, in which we created a datafile at primary site does
> > not exist
> > in the standby site. As another saying, we forgot to create the directory at
> > standby
> > site before adding the datafile to primary site. Now, the standby database
> > is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> > creating the directory, and recovering the database again but nothing
> > changes, however the database becomes suspect again immediately, when we try
> > to restore the log. Please help.......
>

Database became suspect while logshipping and adding a datafile

Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we misse
d
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we mis
sed
> a point. The directory, in which we created a datafile at primary site do
es
> not exist
> in the standby site. As another saying, we forgot to create the directory
at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we t
ry
> to restore the log. Please help.......

Database alterations while Publishing enabled

What are the basic rules for the publisher and subscriber when you wish to
make a database change like adding a column?
- make the change to both databases
- just one and replicate the change
- disable publishing, drop subscriptions before, etc.
Thank you so much ( as I read the current posted subjects),
Bob
Robert,
sp_repladdcolumn and sp_repldropcolumn are the standard way of making schema
changes. Using these procedures, the dependant replication framework (sps,
triggers etc) will be updated as well. Changing existing columns can only be
done in a roundabout way (before SQL 2005). You could add a new column with
the new datatype (sp_repladdcolumn), do an update on the table to populate
the column, then drop the original column (sp_repldropcolumn). Do this again
to create the column having the same original name.
HTH,
Paul Ibison
|||Paul,
After the new columns have been added does the Snapshot have to be run and the subscription reinitialized for the changes to be replicated to the Subscriber? What happens if the subscription is not reinitialised?
Thanks
Chris R
|||Chris,
you only need to synchronize - DON'T ReInitialize whatever you do! -
otherwise a new snapshot will need to be created and then all the articles
will have to go to the subscribers.
HTH,
Paul Ibison

database access & asp.net

If a user has permissions to add and delete rows from a table i.e. adding
and removing items from an order what is to stop a malicious user changing
the product code in the form and then adding to or removing items to/from
another user's order ?
How do we ensure that the rows the user is editing are rows the user has
permission to edit ?
ThanksTwo words Application Architecture. Seriously you need to implement your
own security model if you want to provide for row level and field level
security.
Secondly if you are developing a web app the user should not have rights to
your database. The connection should be handled by an "Application User"
that in turn is managed by a Connection Pool.
Dan
"Murphy" <murphy@.murphy.com> wrote in message
news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> If a user has permissions to add and delete rows from a table i.e. adding
> and removing items from an order what is to stop a malicious user changing
> the product code in the form and then adding to or removing items to/from
> another user's order ?
> How do we ensure that the rows the user is editing are rows the user has
> permission to edit ?
> Thanks
>|||Are there any security models that have been tried and proven, don't want to
reinvent the wheel ?
Thanks
"solex" <solex@.nowhere.com> wrote in message
news:%23oTqDa%23oDHA.708@.TK2MSFTNGP10.phx.gbl...
> Two words Application Architecture. Seriously you need to implement your
> own security model if you want to provide for row level and field level
> security.
> Secondly if you are developing a web app the user should not have rights
to
> your database. The connection should be handled by an "Application User"
> that in turn is managed by a Connection Pool.
> Dan
> "Murphy" <murphy@.murphy.com> wrote in message
> news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> > If a user has permissions to add and delete rows from a table i.e.
adding
> > and removing items from an order what is to stop a malicious user
changing
> > the product code in the form and then adding to or removing items
to/from
> > another user's order ?
> >
> > How do we ensure that the rows the user is editing are rows the user has
> > permission to edit ?
> >
> > Thanks
> >
> >
>|||There are many security models but none that I have seen that will implement
row level security in your database. It has been my experience that if you
want granular security you will need to implement it on your own.
Dan
"Murphy" <murphy@.murphy.com> wrote in message
news:eosI6c%23oDHA.2652@.TK2MSFTNGP09.phx.gbl...
> Are there any security models that have been tried and proven, don't want
to
> reinvent the wheel ?
> Thanks
> "solex" <solex@.nowhere.com> wrote in message
> news:%23oTqDa%23oDHA.708@.TK2MSFTNGP10.phx.gbl...
> > Two words Application Architecture. Seriously you need to implement
your
> > own security model if you want to provide for row level and field level
> > security.
> >
> > Secondly if you are developing a web app the user should not have rights
> to
> > your database. The connection should be handled by an "Application
User"
> > that in turn is managed by a Connection Pool.
> >
> > Dan
> >
> > "Murphy" <murphy@.murphy.com> wrote in message
> > news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> > > If a user has permissions to add and delete rows from a table i.e.
> adding
> > > and removing items from an order what is to stop a malicious user
> changing
> > > the product code in the form and then adding to or removing items
> to/from
> > > another user's order ?
> > >
> > > How do we ensure that the rows the user is editing are rows the user
has
> > > permission to edit ?
> > >
> > > Thanks
> > >
> > >
> >
> >
>

Data Type - DateTime

After adding four datetime related parameters, the following error is
displayed when attempting to run the report. The first two datetime
parameters causes no challenges until the third datetime parameter is added.
An error occurred during local report processing.
An error has occurred during report processing.
Cannot read next data row for the data set IPC_VISION_BCL.
Conversion failed when converting datetime from character string.Hi,
do the parameters are configured as datetime on the VS'
How do u get your dataset by SP'
usually i configure the date parameters as string and in the sp convert them
to the wright format...
"Terry" wrote:
> After adding four datetime related parameters, the following error is
> displayed when attempting to run the report. The first two datetime
> parameters causes no challenges until the third datetime parameter is added.
> An error occurred during local report processing.
> An error has occurred during report processing.
> Cannot read next data row for the data set IPC_VISION_BCL.
> Conversion failed when converting datetime from character string.
>
>