Friday, March 30, 2012
Having trouble creating a login account.
I am trying to create a TEST environment by replicating everything on
the PRODUCTION environment.
When creating a login under Sercurity, I am using the same user name
and passowrd. However, I am getting the following error message:
Password validation failed. The password does not meet Windows policy
requirements becuase it is not complex enough. ( Microsoft SQL Server,
Error: 15118 )
Is there some kind of setting I need to change to have lower
requirements?
Thank you!
Hi,
When a SQL Server 2005 db runs on Windows 2003, there is a way to enforce
password policy.
I believe this is on per login basis. So you should be able to switch this
off while creating a login.
Look for the keyword CHECK_POLICY in BOL 2005.
Thank you.
Regards,
Karthik
"bcap" wrote:
> Hello,
> I am trying to create a TEST environment by replicating everything on
> the PRODUCTION environment.
> When creating a login under Sercurity, I am using the same user name
> and passowrd. However, I am getting the following error message:
> Password validation failed. The password does not meet Windows policy
> requirements becuase it is not complex enough. ( Microsoft SQL Server,
> Error: 15118 )
> Is there some kind of setting I need to change to have lower
> requirements?
> Thank you!
>
Having trouble creating a login account.
I am trying to create a TEST environment by replicating everything on
the PRODUCTION environment.
When creating a login under Sercurity, I am using the same user name
and passowrd. However, I am getting the following error message:
Password validation failed. The password does not meet Windows policy
requirements becuase it is not complex enough. ( Microsoft SQL Server,
Error: 15118 )
Is there some kind of setting I need to change to have lower
requirements?
Thank you!
Hi
"bcap" wrote:
> Hello,
> I am trying to create a TEST environment by replicating everything on
> the PRODUCTION environment.
> When creating a login under Sercurity, I am using the same user name
> and passowrd. However, I am getting the following error message:
> Password validation failed. The password does not meet Windows policy
> requirements becuase it is not complex enough. ( Microsoft SQL Server,
> Error: 15118 )
> Is there some kind of setting I need to change to have lower
> requirements?
> Thank you!
>
I assume this is SQL Server 2005!!
You can create your login using the CREATE LOGIN statement and the option
CHECK_POLICY = OFF which will ignore password policy checking, but you should
really use policy checking on both systems and strong passwords on all
accounts.
John
Having trouble creating a login account.
I am trying to create a TEST environment by replicating everything on
the PRODUCTION environment.
When creating a login under Sercurity, I am using the same user name
and passowrd. However, I am getting the following error message:
Password validation failed. The password does not meet Windows policy
requirements becuase it is not complex enough. ( Microsoft SQL Server,
Error: 15118 )
Is there some kind of setting I need to change to have lower
requirements?
Thank you!Hi
"bcap" wrote:
> Hello,
> I am trying to create a TEST environment by replicating everything on
> the PRODUCTION environment.
> When creating a login under Sercurity, I am using the same user name
> and passowrd. However, I am getting the following error message:
> Password validation failed. The password does not meet Windows policy
> requirements becuase it is not complex enough. ( Microsoft SQL Server,
> Error: 15118 )
> Is there some kind of setting I need to change to have lower
> requirements?
> Thank you!
>
I assume this is SQL Server 2005!!
You can create your login using the CREATE LOGIN statement and the option
CHECK_POLICY = OFF which will ignore password policy checking, but you shoul
d
really use policy checking on both systems and strong passwords on all
accounts.
John
Having trouble creating a login account.
I am trying to create a TEST environment by replicating everything on
the PRODUCTION environment.
When creating a login under Sercurity, I am using the same user name
and passowrd. However, I am getting the following error message:
Password validation failed. The password does not meet Windows policy
requirements becuase it is not complex enough. ( Microsoft SQL Server,
Error: 15118 )
Is there some kind of setting I need to change to have lower
requirements?
Thank you!Hi,
When a SQL Server 2005 db runs on Windows 2003, there is a way to enforce
password policy.
I believe this is on per login basis. So you should be able to switch this
off while creating a login.
Look for the keyword CHECK_POLICY in BOL 2005.
Thank you.
Regards,
Karthik
"bcap" wrote:
> Hello,
> I am trying to create a TEST environment by replicating everything on
> the PRODUCTION environment.
> When creating a login under Sercurity, I am using the same user name
> and passowrd. However, I am getting the following error message:
> Password validation failed. The password does not meet Windows policy
> requirements becuase it is not complex enough. ( Microsoft SQL Server,
> Error: 15118 )
> Is there some kind of setting I need to change to have lower
> requirements?
> Thank you!
>sql
Having trouble creating a login account.
I am trying to create a TEST environment by replicating everything on
the PRODUCTION environment.
When creating a login under Sercurity, I am using the same user name
and passowrd. However, I am getting the following error message:
Password validation failed. The password does not meet Windows policy
requirements becuase it is not complex enough. ( Microsoft SQL Server,
Error: 15118 )
Is there some kind of setting I need to change to have lower
requirements?
Thank you!Hi
"bcap" wrote:
> Hello,
> I am trying to create a TEST environment by replicating everything on
> the PRODUCTION environment.
> When creating a login under Sercurity, I am using the same user name
> and passowrd. However, I am getting the following error message:
> Password validation failed. The password does not meet Windows policy
> requirements becuase it is not complex enough. ( Microsoft SQL Server,
> Error: 15118 )
> Is there some kind of setting I need to change to have lower
> requirements?
> Thank you!
>
I assume this is SQL Server 2005!!
You can create your login using the CREATE LOGIN statement and the option
CHECK_POLICY = OFF which will ignore password policy checking, but you should
really use policy checking on both systems and strong passwords on all
accounts.
John
Monday, February 27, 2012
Handling merge replication foreign key conflicts
What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.
This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.
Thanks.
Any ideas on this?|||
presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows
- whether DRI or by trigger
if you were using transactional replication the delete child-then-parent would be part of same atomic transaction
- thus maybe you would get both or neither.
possibly using transactional repl with immediate updating would avoid updates to such ghosts.
however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation
seems that you could
1. write custom resolvers, or
2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]
3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]
HTH
Dick
Handling merge replication foreign key conflicts
What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.
This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.
Thanks.
Any ideas on this?|||
presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows
- whether DRI or by trigger
if you were using transactional replication the delete child-then-parent would be part of same atomic transaction
- thus maybe you would get both or neither.
possibly using transactional repl with immediate updating would avoid updates to such ghosts.
however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation
seems that you could
1. write custom resolvers, or
2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]
3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]
HTH
Dick
Handling merge replication foreign key conflicts
What I would like to happen is to have the table B records on the client be deleted by the merge process, and to create a log of the event. I've looked into creating a business logic handler to do this, but I'm not sure what type of conflict this is (UpdateDeleteConflict or otherwise), and I'm not sure that deleting the table B records is something I can do in the business logic handler.
This seems like it would be a common problem in merge replication. I'm not locked into using a custom business logic handler at all. Any suggestions are welcome.
Thanks.
Any ideas on this?|||
presumably you have a CASCADE DELETE to trash the child ("table B") whenever you delete the parent ("tableA") rows
- whether DRI or by trigger
if you were using transactional replication the delete child-then-parent would be part of same atomic transaction
- thus maybe you would get both or neither.
possibly using transactional repl with immediate updating would avoid updates to such ghosts.
however using merge repl [yes I recognise its benefits!] will inevitably have to cope with unconstrained race conditions across the fabric. therefore you would have to cope with this situation
seems that you could
1. write custom resolvers, or
2. delve into the guts of the sprocs that actually execute the I/U/D statements [or use insteadof triggers]
3. simply add extra IsDeleted flag on each tableA,tableB table for soft-delete [actually do hard-delete at quiet time]
HTH
Dick