09-15-2008 01:44 PM
I have a client that can not delete sub entities unless the system clock is set back to a date before the 13th on the month.
US: 9/13/2008 delete OK
German: 13/9/2008 thows this error.
Or is there a planned hotfix.
-- jim durkin
MESSAGE: Invalid processor county. Processor not currently in a transaction.
SOURCE : Act.Data
STACK: at Act.Data.CommandProcessor.EndTransaction() at Act.Framework.CustomEntities.CustomEntityManagerDB`1.RemoveData(T data) at Act.Shared.Collections.DataList`1.Remove(T value) at Act.Shared.Collections.DataList`1.System.Collections.IList.Remove(Object value) at System.Windows.Forms.BindingSource.Remove(Object value) at Durkin.Common.Classes.CustomSubEntity.SubEntityItemDelete(BindingSource cEntityBindingSource, CustomSubEntityDurkin cSubEntityItem)
TIME: 15.09.2008 03:11:55
ACT NAME: ActSage, Version=11.0.367.0, Culture=neutral, PublicKeyToken=ebf6b2ff4d0a08aa
---- Stack Trace ----
Stack:0: Durkin.Common.Utilities.DisplayError.Write(myException As Exception, sRoutine As String, sPluginName As String, sPluginVersion As String, sEmailFromAddress As String, sFromFullName As String) ActSage.exe: N 05007
Stack:1: Durkin.Common.Classes.LogError.Write(myException As Exception, sDescription As String) ActSage.exe: N 00329
Stack:2: Durkin.Common.Classes.CustomSubEntity.SubEntityItemDelete(cEntityBindingSource As BindingSource, cSubEntityItem As CustomSubEntityDurkin) ActSage.exe: N 00188
Stack:3: Durkin.UI.Toolkit.usrEntityGridExControl.SubItemDelete(mGridEX As GridEX) ActSage.exe: N 00753
09-18-2008 03:48 PM
I can confirm that my tests have shown this kind of error not only shows up while deleting sub entity records,
but all kind of other functions "bounce" on and after the 13th day of month in the English Europe Version.
Actually I had tested some issues on Friday 12th of Sept and everything worked as expected,
when I used the same machine on the next day it gave all kinds of errors.
I can pinpoint it's logic to what another addon developer told me:
In the Europe version dates seem to be stored in DD/MM/YYYY
but the SDK tries to write a MM/DD/YYYY format into those fields.
So the 13th Sept is expected as 13/09/yyyy.
When SDK sends the value as 09/13/yyyy this is rejected as wrong (13th month).
By setting the systemdate back the function works - but this can be done only in test environment, in live
installations the systemdate is automatically corrected by the Timesync server so quick that it will not allow
This can be solved probably only by adopting the SDK - making it ask for the ACT country version
and adjusting the dates accordingly.
If this is not corrected literally all addons that working with date values
are are limited to US & UK customer usage only.
Actually I really do not understand why the different regional ACT versions use hardcoded field settings
in the SQL databases. This is not only annoying but this seems to be the main reason that we can not have
a real mixed language approach with ACT.
Planning for a team that spans several European countries I have to setup separated databases for each region
although the structure and fieldlist is 99% common to all teams - which multiplies the administrative effort
by number of languages spoken.
Otherwise we could put all data records into one common database
and allow each team to use a customized layout view.
To look over the fence:
I am working with SAP on installations that have one common database set up to
cover a companies worldwide offices. Each user can freely select his display language and
international parameters without caring about the database structure. i.e.
date format [x] DD.MM.YYYY decimals [ ] 1.234.567,89 Language [EN] or DE, FR, SP, ....
[ ] MM/DD/YYYY [ ] 1,234,567.89 any unicode possibility
[ ] YYYY-MM-DD
The only top level decision to take when setting up the database is all currency entries are in $, Yen or €
depending on the Headoffice balancing currency, but with SAP you can even have a special setup to define
a local differnt currency input. Nowadays in Europe the € is common so we would have no need for that anyhow.
Adding that feature to ACT would be a great plus and a big advantage over other CRM competition products...
But that is for the future.
Currently I am looking urgently forward to get that bug exterminated from the SDK quickly,
otherwise I can not use the addons written with that SDK version.