The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 07 Mar 09 3:54 PM
|
Here are the results of my tests let me know if for some reason what I'm seeing doesn't seem totally wrong?
I'm MST
Running the UPDATE and SELECT through the provider... So I updated a FIELD through the provider than retrieved that field directly after the update
UpdatedWith: 3/7/2009 6:00:00 PM ReturnedFromProvider: 3/7/2009 6:00:00 PM Difference: 0
UpdatedWith: 3/7/2009 7:00:00 PM ReturnedFromProvider: 3/7/2009 8:00:00 PM Difference: -1
UpdatedWith: 3/7/2009 8:00:00 PM ReturnedFromProvider: 3/7/2009 9:00:00 PM Difference: -1
UpdatedWith: 3/7/2009 9:00:00 PM ReturnedFromProvider: 3/7/2009 10:00:00 PM Difference: -1
UpdatedWith: 3/7/2009 10:00:00 PM ReturnedFromProvider: 3/7/2009 11:00:00 PM Difference: -1
UpdatedWith: 3/7/2009 11:00:00 PM ReturnedFromProvider: 3/8/2009 12:00:00 AM Difference: -1
UpdatedWith: 3/8/2009 12:00:00 AM ReturnedFromProvider: 3/8/2009 1:00:00 AM Difference: -1
UpdatedWith: 3/8/2009 1:00:00 AM ReturnedFromProvider: 3/8/2009 2:00:00 AM Difference: -1
UpdatedWith: 3/8/2009 2:00:00 AM ReturnedFromProvider: 3/8/2009 2:00:00 AM Difference: 0
Now I ran the same test running the updates outside the provider
UpdatedWith (NoProvider so GMT): 3/8/2009 12:00:00 AM ReturnedFromProvider: 3/7/2009 5:00:00 PM Difference: 7
UpdatedWith (NoProvider so GMT): 3/8/2009 1:00:00 AM ReturnedFromProvider: 3/7/2009 6:00:00 PM Difference: 7
UpdatedWith (NoProvider so GMT): 3/8/2009 2:00:00 AM ReturnedFromProvider: 3/7/2009 8:00:00 PM Difference: 6
UpdatedWith (NoProvider so GMT): 3/8/2009 3:00:00 AM ReturnedFromProvider: 3/7/2009 9:00:00 PM Difference: 6
The first result should ALWAYS return a difference of 0
The second result shouldn't cause a time shift at 2 AM GMT
DST is relative to your location so it should wait until it hits MST 2 AM before it returns a forwarded hour
right?
Am I missing osmething? |
|
|
| |
| |
| |
| |
|
Re: The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 14 Mar 09 1:35 PM
|
Here's my code written directly against OLEDb Connections
I've ran this code on two different computers both with the exact same results
1) my home system
2) a system within the company network
The other problem I described running directly with the SLX Client
If I go into the SLX Client
Bring up a Ticket
Update the NEeded By Date to
03/07/2009 8 pm
Click save
Reload the ticket
the needed by date is now
03/07/2009 9 pm
This behavior has been seen on:
My computer
a separate development system (housed at the location of the company within there network)
And (as far as I know) on every single persons computer using the SLX Client in our call center
The 1 hour drift was noticed on 3 production web servers (running against production instances of SLX)
Our build server (Running against a development instance of SLX)
and our staging server (running against a staging instance of SLX)
Here's my test code
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
//in the form of
//"Provider=SLXOLEDB.1;Data Source=SLXSERVER;Initial Catalog=CATALOG ersist Security Info=True;User ID=USERIDassword=PASSWORDort=1706;"
string slxProviderConnection = ConfigurationManager.ConnectionStrings["SLXConnectionString"].ConnectionString;
//in the form of
//"Data Source=SERVER;Initial Catalog=CATALOGersist Security Info=True;User ID=USERIDassword=PASSWORD;"
string straightSQLConnection = ConfigurationManager.ConnectionStrings["SLXSQLClient"].ConnectionString;
DateTime myTime = new DateTime(2009,3,7);
for (int i = 0; i < 24;i++)
{
DateTime? throughProvider = null;
using (OleDbConnection conn = new OleDbConnection(slxProviderConnection))
{
conn.Open();
using (OleDbCommand cmd = new OleDbCommand("Update Ticket SET CompletedDate = ? WHERE TicketId = 't6UJ9A002S1X'", conn))
{
cmd.Parameters.Add(
"@p0", OleDbType.DBTimeStamp, 8);
cmd.Parameters[0].Value = myTime;
cmd.ExecuteNonQuery();
}
using (OleDbCommand cmd = new OleDbCommand("Select CompletedDate FROM Ticket WHERE TicketId = 't6UJ9A002S1X'", conn))
{
throughProvider = Convert.ToDateTime(cmd.ExecuteScalar());
}
}
Response.Write(
String.Format("Updated With Provider: {0} ReturnedFromProvider: {1} Difference: {2}",
myTime, throughProvider, myTime.Subtract(throughProvider.Value).TotalHours));
myTime = myTime.AddHours(1);
Response.Write("
");
}
Response.Write("
"); Response.Write("
"); Response.Write("
");
myTime = new DateTime(2009, 3, 7);
for (int i = 0; i < 48; i++)
{
DateTime? throughProvider = null;
using (SqlConnection conn = new SqlConnection(straightSQLConnection))
{
conn.Open();
using (SqlCommand cmd = new SqlCommand(
String.Format("Update Ticket SET CompletedDate = @p0 WHERE TicketId = 't6UJ9A002S1X'", myTime)
, conn))
{
cmd.Parameters.AddWithValue("@p0", myTime);
cmd.ExecuteNonQuery();
}
}
using (OleDbConnection conn = new OleDbConnection(slxProviderConnection))
{
conn.Open();
using (OleDbCommand cmd = new OleDbCommand("Select CompletedDate FROM Ticket WHERE TicketId = 't6UJ9A002S1X'", conn))
{
throughProvider = Convert.ToDateTime(cmd.ExecuteScalar());
}
}
Response.Write(
String.Format("Updated With No Provider so GMT: {0} ReturnedFromProvider: {1} Difference: {2}",
myTime, throughProvider, myTime.Subtract(throughProvider.Value).TotalHours));
myTime = myTime.AddHours(1);
Response.Write("
");
}
}
We sent all this to SLX and they've been so far very unhelpful...
Also I think they have an internal rule that no ones allowed to open this website...
We referred to this post for use cases of the error and all they had to say was "we don't affiliate with that site"
Just thought that was weird...
But whatever anyone have insight?
that'd be awesome
cause it's annoying that twice a year for like 8 hours all our business rules based on time dependencies are going to fail
And it'll cost a lot of development to provide our fixes around the SLX black box |
|
|
|
Re: The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 15 Mar 09 8:19 AM
|
Ever since SlesLogix was changed to deal w/GMT.. it's been a well known fact there is a "black hole" that happens around teh spring and fall windows.
Basically.. you need to code things to completely avoid this window. Since it always happens over a weekend the impact doesn't touch enough users/customers for Sage to ever fix it.. IF they can fix it.
You CAN make tz calls to check to see if you are in that hole/window and adjust your data.. that's really all you can do.
--
RJLedger - www.rjlSystems.net |
|
|
|
Re: The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 15 Mar 09 5:35 PM
|
It's been a well known fact there is a "black hole" that happens around teh spring and fall windows.
|
|
Has it?
Is there somewhere that I can see a list of or get a hold of these well known facts?
Does SLX know about these well known facts?
Cause we've been trying to convince them for the past 3 months about this hole and they just keep coming back and telling us we're wrong and that it's our problem to deal with.
There seems to be a large amount of "facts" and caveats when dealing with the SLX provider that aren't documented anywhere....
Plus I think SLX hates this site... We gave them this thread as a reference of use cases and before we could take a breath they responded.
WE DON'T AFFILIATE WITH THAT SITE.
It seems like anything that doesn't give them total power and control (with financial gain to themselves) over the random esoteric knowledge required to operate SLX really ticks them off..
I personally can't stand the SLX Provider..
Especially given that things like these "holes" are common knowledge yet still remain unsupported and undocumented.
I'm really hoping that the web service based system in 7.5 isn't equally as infuriating...
Thank god we noticed this or else it would have been a huge fiasco when our extremely important time oriented events all drifted to 2 am w/o us knowing..... |
|
|
|
Re: The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 15 Mar 09 7:14 PM
|
A - No there is no list that's available to the "public". When a release is done, there is a Known Issues and Fixed Issues list that is created. Your BP has access to that list and (sometimes) it's updated on the SalesLogix Support site.
B - There is a "defects" list that is internal to Sage SalesLogix but even BP's do not have (direct) access to that list. It's an up to date list.
C - For obvious legal reasons, Sage SalesLogix does not endorse/support any site that is not under their control. Off the "home page" of this site:
slxdeveloper.com is built & maintained by Ryan Farley and brought to you courtesy of Customer FX Corporation
D - Well.. you are "stuck" w/the SLX Provider.. it's a core element of SalesLogix. The present versions started at 6.2.0 and continues to be enhanced.. 8.0 will have it.. that's the way it goes.
E - Your BP should have told you about this problem.. it's something that came up a long time in the SalesLogix Partner's News Group.. and no.. it is not open to the public or customers.. it's a BP thing only - maintained by Sage SalesLogix for it's partners.
--
RJLedger - www.rjlSystems.net
|
|
|
|
Re: The SLX Provider doesn't take into account Time Zone when accounting for DST
Posted: 15 Mar 09 8:23 PM
|
Originally posted by Bob (RJ)Ledger
A - No there is no list that's available to the "public". When a release is done, there is a Known Issues and Fixed Issues list that is created. Your BP has access to that list and (sometimes) it's updated on the SalesLogix Support site.
B - There is a "defects" list that is internal to Sage SalesLogix but even BP's do not have (direct) access to that list. It's an up to date list.
C - For obvious legal reasons, Sage SalesLogix does not endorse/support any site that is not under their control. Off the "home page" of this site:
slxdeveloper.com is built & maintained by Ryan Farley and brought to you courtesy of Customer FX Corporation
D - Well.. you are "stuck" w/the SLX Provider.. it's a core element of SalesLogix. The present versions started at 6.2.0 and continues to be enhanced.. 8.0 will have it.. that's the way it goes.
E - Your BP should have told you about this problem.. it's something that came up a long time in teh SalesLogix Partner's News Group.. and no.. it is not open to the public or customers.. it's a BP thing only - maintained by Sage SalesLogix for it's partners.
--
RJLedger - www.rjlSystems.net
|
|
Exactly...
Thank you for the validation 
|
|
|
|