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!
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!
>
Showing posts with label environment. Show all posts
Showing posts with label environment. Show all posts
Friday, March 30, 2012
Having trouble creating a login account.
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!
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
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.
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!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
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.
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!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
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.
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!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
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, March 12, 2012
Hardware Recommendations/advice
Any great links or advice on buying mid-to-high-end hardware for a SQL 2000
OLTP environment?
I'm trying to get the most bang for my buck and have about $80K-$125K for
hardware. My primary need is for lots of I/O. Trying to decide between
multiple SCSI channels or a newer generation FC SAN solution. I know I want
at least 28 physical disks connected to the system. Thinking of either a
Clustered SAN solution or shared-nothing (mirroring/log shipping) for
redundancy.
I've got a total of 68 databases to run on it. The largest is about 80G of
data; most are pretty small (200-500Mbytes). Total is about 120G of data and
10G of transaction log files. Looking for substantially greater I/O capacity
(especially write) and considering servers with 8G or more of RAM to better
cache the data and reduce I/O requirements. Not needing a ton of CPU power.
Currently 4 550Mhz xeons handle the load running at 20% CPU pretty easily.
Thinking a modern 2CPU system (Xeon, Opteron, or Itanium) would provide
plenty of CPU for my needs as it will be faster than my current server.
Currently running 1999 era hardware (and wanting at least 2-3 times I/O
capacity for future growth):
Dell 2650 with 4 550Mhz Xeons, 4Gbytes of RAM
Dell 650F FC SAN (1Gbit, 512M cache), 30 15K RPM disks
Thanks for any help!!
Phil MattsonPhillip,
That's a big decision to make over a few newsgroup posts but here are some
general comments. If your looking for lots of IO then a SAN is a good
choice. You can start out with a minimal config to keep costs down but will
have room to grow if needed. If your really talking 70 DB's then you should
probably give more thought to a clustered solution vs Log shipping. It can
get to be a nightmare if you have to fail over 70 DB's at one time with Log
shipping. A word of caution in going from 4 cpu's to 2. Although the newer
cpu's would be much faster there are times when more vs faster can be
beneficial when you have lots of users. If you are running at 20% or less
now it may be OK but you need to get a handle on how much parallel
operations are occurring now and how they are used.
--
Andrew J. Kelly SQL MVP
"Philip Mattson" <philm@.nwsoft.com> wrote in message
news:%23N6c15HjEHA.1040@.TK2MSFTNGP09.phx.gbl...
> Any great links or advice on buying mid-to-high-end hardware for a SQL
2000
> OLTP environment?
> I'm trying to get the most bang for my buck and have about $80K-$125K for
> hardware. My primary need is for lots of I/O. Trying to decide between
> multiple SCSI channels or a newer generation FC SAN solution. I know I
want
> at least 28 physical disks connected to the system. Thinking of either a
> Clustered SAN solution or shared-nothing (mirroring/log shipping) for
> redundancy.
> I've got a total of 68 databases to run on it. The largest is about 80G of
> data; most are pretty small (200-500Mbytes). Total is about 120G of data
and
> 10G of transaction log files. Looking for substantially greater I/O
capacity
> (especially write) and considering servers with 8G or more of RAM to
better
> cache the data and reduce I/O requirements. Not needing a ton of CPU
power.
> Currently 4 550Mhz xeons handle the load running at 20% CPU pretty easily.
> Thinking a modern 2CPU system (Xeon, Opteron, or Itanium) would provide
> plenty of CPU for my needs as it will be faster than my current server.
> Currently running 1999 era hardware (and wanting at least 2-3 times I/O
> capacity for future growth):
> Dell 2650 with 4 550Mhz Xeons, 4Gbytes of RAM
> Dell 650F FC SAN (1Gbit, 512M cache), 30 15K RPM disks
>
> Thanks for any help!!
> Phil Mattson
>
>
OLTP environment?
I'm trying to get the most bang for my buck and have about $80K-$125K for
hardware. My primary need is for lots of I/O. Trying to decide between
multiple SCSI channels or a newer generation FC SAN solution. I know I want
at least 28 physical disks connected to the system. Thinking of either a
Clustered SAN solution or shared-nothing (mirroring/log shipping) for
redundancy.
I've got a total of 68 databases to run on it. The largest is about 80G of
data; most are pretty small (200-500Mbytes). Total is about 120G of data and
10G of transaction log files. Looking for substantially greater I/O capacity
(especially write) and considering servers with 8G or more of RAM to better
cache the data and reduce I/O requirements. Not needing a ton of CPU power.
Currently 4 550Mhz xeons handle the load running at 20% CPU pretty easily.
Thinking a modern 2CPU system (Xeon, Opteron, or Itanium) would provide
plenty of CPU for my needs as it will be faster than my current server.
Currently running 1999 era hardware (and wanting at least 2-3 times I/O
capacity for future growth):
Dell 2650 with 4 550Mhz Xeons, 4Gbytes of RAM
Dell 650F FC SAN (1Gbit, 512M cache), 30 15K RPM disks
Thanks for any help!!
Phil MattsonPhillip,
That's a big decision to make over a few newsgroup posts but here are some
general comments. If your looking for lots of IO then a SAN is a good
choice. You can start out with a minimal config to keep costs down but will
have room to grow if needed. If your really talking 70 DB's then you should
probably give more thought to a clustered solution vs Log shipping. It can
get to be a nightmare if you have to fail over 70 DB's at one time with Log
shipping. A word of caution in going from 4 cpu's to 2. Although the newer
cpu's would be much faster there are times when more vs faster can be
beneficial when you have lots of users. If you are running at 20% or less
now it may be OK but you need to get a handle on how much parallel
operations are occurring now and how they are used.
--
Andrew J. Kelly SQL MVP
"Philip Mattson" <philm@.nwsoft.com> wrote in message
news:%23N6c15HjEHA.1040@.TK2MSFTNGP09.phx.gbl...
> Any great links or advice on buying mid-to-high-end hardware for a SQL
2000
> OLTP environment?
> I'm trying to get the most bang for my buck and have about $80K-$125K for
> hardware. My primary need is for lots of I/O. Trying to decide between
> multiple SCSI channels or a newer generation FC SAN solution. I know I
want
> at least 28 physical disks connected to the system. Thinking of either a
> Clustered SAN solution or shared-nothing (mirroring/log shipping) for
> redundancy.
> I've got a total of 68 databases to run on it. The largest is about 80G of
> data; most are pretty small (200-500Mbytes). Total is about 120G of data
and
> 10G of transaction log files. Looking for substantially greater I/O
capacity
> (especially write) and considering servers with 8G or more of RAM to
better
> cache the data and reduce I/O requirements. Not needing a ton of CPU
power.
> Currently 4 550Mhz xeons handle the load running at 20% CPU pretty easily.
> Thinking a modern 2CPU system (Xeon, Opteron, or Itanium) would provide
> plenty of CPU for my needs as it will be faster than my current server.
> Currently running 1999 era hardware (and wanting at least 2-3 times I/O
> capacity for future growth):
> Dell 2650 with 4 550Mhz Xeons, 4Gbytes of RAM
> Dell 650F FC SAN (1Gbit, 512M cache), 30 15K RPM disks
>
> Thanks for any help!!
> Phil Mattson
>
>
Friday, February 24, 2012
handling different Timezones
I planning on using replication(merge most likely) in an environment where
the subscribers will be in different timezones. Is there way to convert the
datetime fields from the subscriber's to the local database timezone to the
publishers, and vice versa?
Thanks
+---+
William F. Kinsley
Sr. Design Engineer
NextGen Healthcare Info. Sys. Inc
Normally this is done on the application level.
There is no way, other than storing the time as UTC or with time zone
information, that I am aware of doing this.
"William F. Kinsley" <bacardi@.online.nospam> wrote in message
news:%23s5YuzHuEHA.1280@.TK2MSFTNGP10.phx.gbl...
>I planning on using replication(merge most likely) in an environment where
> the subscribers will be in different timezones. Is there way to convert
> the
> datetime fields from the subscriber's to the local database timezone to
> the
> publishers, and vice versa?
> Thanks
> --
> +---+
> William F. Kinsley
> Sr. Design Engineer
> NextGen Healthcare Info. Sys. Inc
>
|||Hi William,
Thanks for your post.
From your descriptions, I understood you would like to know whether there
will be any problems when replicating between different time zones. Have I
understood you? Correct me if I was wrong.
Based on my scope, it won't. We know of many cases where merge is
successfully running across time zones (merge wouldn't be too valuable if
it couldn't ). If you have a look at the usage of getdate in merge's stored
procuedres(identifying those stored procedures would have been useful ),
you will find that merge history tables' use of a datetime (that was
created by getdate) should not be a concern.
Additionally, there is some BOL excerpt for your reference
============
The generation column in these tables acts as a logical clock indicating
when a row was last updated at a given site. Actual datetime values are not
used for marking when changes occur, or deciding conflicts, and there is no
dependence on synchronized clocks between sites. This makes the conflict
detection and resolution algorithms more resilient to time zone differences
and differences between physical clocks on multiple servers. At a given
site, the generation numbers correspond to the order in which changes were
performed by the Merge Agent or by a user at that site.
============
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Thanks for such a detailed reply, this was really not my question, but still
was very helpful. My question is, if I have a user table with a datetime
column, is there a way for the replication process to automatically convert
the datetime from the source databases timezone to the target database's
time zone? I would prefer not to store everything as UTC since I will have
user created reporting on the data.
Thanks
Bill
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:VIGUFEMuEHA.464@.cpmsftngxa10.phx.gbl...
> Hi William,
> Thanks for your post.
> From your descriptions, I understood you would like to know whether there
> will be any problems when replicating between different time zones. Have I
> understood you? Correct me if I was wrong.
> Based on my scope, it won't. We know of many cases where merge is
> successfully running across time zones (merge wouldn't be too valuable if
> it couldn't ). If you have a look at the usage of getdate in merge's
stored
> procuedres(identifying those stored procedures would have been useful ),
> you will find that merge history tables' use of a datetime (that was
> created by getdate) should not be a concern.
> Additionally, there is some BOL excerpt for your reference
> ============
> The generation column in these tables acts as a logical clock indicating
> when a row was last updated at a given site. Actual datetime values are
not
> used for marking when changes occur, or deciding conflicts, and there is
no
> dependence on synchronized clocks between sites. This makes the conflict
> detection and resolution algorithms more resilient to time zone
differences
> and differences between physical clocks on multiple servers. At a given
> site, the generation numbers correspond to the order in which changes were
> performed by the Merge Agent or by a user at that site.
> ============
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
I am sorry for my poor understanding.
If so, I think, as Hilary Cotter had said, there is no such funcationality
provided in SQL Server 2000 and you will have to do it in application
level.
However, it is a great idea to have such expand feature and I'd recommend
that you forward the recommendation to the Microsoft Wish Program:
mswish@.microsoft.com.
Hope the this will be considered in the furture version of SQL Server.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||I was afraid that was going to be the answer, Thank you for your help
Bill
""Michael Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:qBXAuAmuEHA.2692@.cpmsftngxa10.phx.gbl...
> Hi Bill,
> I am sorry for my poor understanding.
> If so, I think, as Hilary Cotter had said, there is no such funcationality
> provided in SQL Server 2000 and you will have to do it in application
> level.
> However, it is a great idea to have such expand feature and I'd recommend
> that you forward the recommendation to the Microsoft Wish Program:
> mswish@.microsoft.com.
> Hope the this will be considered in the furture version of SQL Server.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
Welcome!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
the subscribers will be in different timezones. Is there way to convert the
datetime fields from the subscriber's to the local database timezone to the
publishers, and vice versa?
Thanks
+---+
William F. Kinsley
Sr. Design Engineer
NextGen Healthcare Info. Sys. Inc
Normally this is done on the application level.
There is no way, other than storing the time as UTC or with time zone
information, that I am aware of doing this.
"William F. Kinsley" <bacardi@.online.nospam> wrote in message
news:%23s5YuzHuEHA.1280@.TK2MSFTNGP10.phx.gbl...
>I planning on using replication(merge most likely) in an environment where
> the subscribers will be in different timezones. Is there way to convert
> the
> datetime fields from the subscriber's to the local database timezone to
> the
> publishers, and vice versa?
> Thanks
> --
> +---+
> William F. Kinsley
> Sr. Design Engineer
> NextGen Healthcare Info. Sys. Inc
>
|||Hi William,
Thanks for your post.
From your descriptions, I understood you would like to know whether there
will be any problems when replicating between different time zones. Have I
understood you? Correct me if I was wrong.
Based on my scope, it won't. We know of many cases where merge is
successfully running across time zones (merge wouldn't be too valuable if
it couldn't ). If you have a look at the usage of getdate in merge's stored
procuedres(identifying those stored procedures would have been useful ),
you will find that merge history tables' use of a datetime (that was
created by getdate) should not be a concern.
Additionally, there is some BOL excerpt for your reference
============
The generation column in these tables acts as a logical clock indicating
when a row was last updated at a given site. Actual datetime values are not
used for marking when changes occur, or deciding conflicts, and there is no
dependence on synchronized clocks between sites. This makes the conflict
detection and resolution algorithms more resilient to time zone differences
and differences between physical clocks on multiple servers. At a given
site, the generation numbers correspond to the order in which changes were
performed by the Merge Agent or by a user at that site.
============
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Thanks for such a detailed reply, this was really not my question, but still
was very helpful. My question is, if I have a user table with a datetime
column, is there a way for the replication process to automatically convert
the datetime from the source databases timezone to the target database's
time zone? I would prefer not to store everything as UTC since I will have
user created reporting on the data.
Thanks
Bill
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:VIGUFEMuEHA.464@.cpmsftngxa10.phx.gbl...
> Hi William,
> Thanks for your post.
> From your descriptions, I understood you would like to know whether there
> will be any problems when replicating between different time zones. Have I
> understood you? Correct me if I was wrong.
> Based on my scope, it won't. We know of many cases where merge is
> successfully running across time zones (merge wouldn't be too valuable if
> it couldn't ). If you have a look at the usage of getdate in merge's
stored
> procuedres(identifying those stored procedures would have been useful ),
> you will find that merge history tables' use of a datetime (that was
> created by getdate) should not be a concern.
> Additionally, there is some BOL excerpt for your reference
> ============
> The generation column in these tables acts as a logical clock indicating
> when a row was last updated at a given site. Actual datetime values are
not
> used for marking when changes occur, or deciding conflicts, and there is
no
> dependence on synchronized clocks between sites. This makes the conflict
> detection and resolution algorithms more resilient to time zone
differences
> and differences between physical clocks on multiple servers. At a given
> site, the generation numbers correspond to the order in which changes were
> performed by the Merge Agent or by a user at that site.
> ============
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
I am sorry for my poor understanding.
If so, I think, as Hilary Cotter had said, there is no such funcationality
provided in SQL Server 2000 and you will have to do it in application
level.
However, it is a great idea to have such expand feature and I'd recommend
that you forward the recommendation to the Microsoft Wish Program:
mswish@.microsoft.com.
Hope the this will be considered in the furture version of SQL Server.
Thank you for your patience and corperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||I was afraid that was going to be the answer, Thank you for your help
Bill
""Michael Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:qBXAuAmuEHA.2692@.cpmsftngxa10.phx.gbl...
> Hi Bill,
> I am sorry for my poor understanding.
> If so, I think, as Hilary Cotter had said, there is no such funcationality
> provided in SQL Server 2000 and you will have to do it in application
> level.
> However, it is a great idea to have such expand feature and I'd recommend
> that you forward the recommendation to the Microsoft Wish Program:
> mswish@.microsoft.com.
> Hope the this will be considered in the furture version of SQL Server.
> Thank you for your patience and corperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Michael Cheng
> Online Partner Support Specialist
> Partner Support Group
> Microsoft Global Technical Support Center
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Bill,
Welcome!
Sincerely yours,
Michael Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
Subscribe to:
Posts (Atom)