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!
|
|
Another GMT Question ?! datetimetype = 'z'
Posted: 25 May 06 11:13 AM
|
does generic viagra work generic viagra fiogf49gjkf0d Hi All,
6.2.3 , SQL2000
I was wondering if any of you folks have run across this 'feature' and could explain it to me.
When I run the following query through Query Analyzer, I get a proper result set:
SELECT activityid, startdate FROM Activity WHERE startdate > '2006-05-01'
However, If I run that exact query through Execute SQL, It will fail to parse. It will parse if you add the 00:00:00 (time) to it.
This holds true for the following 5 fields 
SELECT * from sectabledefs WHERE datetimetype = 'z'
Activity.Startdate
Activity.AlarmTime
Activity.OriginalDate
History.Startdate
History.OriginalDate
Does anyone know what the provider is reading or doing specifically with these fields?
Carla
|
|
|
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 25 May 06 6:23 PM
|
fiogf49gjkf0d Not sure. The docs say:
| "Z" is reserved, is unsupported by third party use, and is not guaranteed to be supported in future versions of SalesLogix. |
|
 |
|
|
| |
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 26 May 06 10:58 PM
|
otc asthma inhaler rite aid otc asthma inhaler walgreens fiogf49gjkf0d 'z' signifies that this GMT conversion should be conditional for this field.
For example - SLX activities can be flagged as occuring on a specific date and time OR one a specific date, but "timeless". What this means is that values for this field for some records should be converted to/from GMT while for other records GMT conversion should NOT be performed.
If you flag an activity as "timeless" you will find that the datetime value stored in Activity.Startdate will be a date with a time value of 00:00:05 - this is a special time value that SLX uses to determine at run time that GMT conversion should NOT be performed for this specific field on this specific record.
While this is technically an unsupported feature, if I felt I had a need for this kind of behaviour for a custmization, I would go ahead and use it as this is pretty unlikely to change in SLX v6.x and v7.x, and if it does - I am guessing that an alternative feature woudl become available - just my opinion of course.
|
|
|
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 27 May 06 1:42 AM
|
fiogf49gjkf0d So, if I read between the lines on what you are saying,
If the date caries the 'z' code,
If the time is 00:00:05 , it is treated as a date only,
else it is treated as a DateTime (hence the "conditional" z).
Thank you Todd for the great piece of info here..
|
|
|
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 30 May 06 8:00 AM
|
fiogf49gjkf0d Thanks Todd, I will work with that information; but may have a few more questions!
For reference:
I ran into issues when handling these fields in custom code. I ended up adding a time value to any SQL calls that use StartDate, etc.
i.e.
myDate = '2006-05-30 00.00.00' as opposed to WHERE StartDate > '2006-05-30' .
It certainly threw me a loop as other datetime fields can be handled without a time value. So the word 'feature' didn't quite apply at the time...
Carla
|
|
|
| |
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 02 Jun 06 12:10 PM
|
buy albuterol sulfate buy albuterol sulfate online buy ventolin inhaler over the counter buy venlafaxine online uk buy venlafaxine 75 mg website fiogf49gjkf0d <
For reference:
I ran into issues when handling these fields in custom code. I ended up adding a time value to any SQL calls that use StartDate, etc.
i.e.
myDate = '2006-05-30 00.00.00' as opposed to WHERE StartDate > '2006-05-30' .
>
Ahh, yes. Sorry I did not spot that in your SQL earlier.
In fact, I very strictly follow the full ISO format all the time in order to avoid any odd Parsing or Sync errors.
Actually, what I most often do is try to avoid "raw" SQL statements and instead use parameterized ADO commands and/or ADO recordsets as all the parmeters and/or fields are typed so you can use an actual DateTime value rather than a string. This avoids all these odd problems and is the techniue recommended by Stu Carnie - the SLX lead architect and SLX OleDB developer/guru.
Todd
|
|
|
| |
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 02 Jun 06 12:55 PM
|
when does viagra go generic cheap generic viagra read fiogf49gjkf0d Not to pat myself on the back or anything  ...
That is actually the function that I posted to the SLX BP community newsgroups. There were several of us (Ryan Farley, Mike Spragg, Stephen Redmond) that created and colaborated on similar functions at that time and have shared them freely to everyone... so no harm no foul at all.
Note that in SLX v6.2 you can just use the built-in function in SLX
application.basicfunctions.DateToISO(dDate)
I really can't emphasize enough though that the preferred technique is to not use raw SQL anymore as the SLX OleDB provider is much better able to deal with parameterized commands and ADO recordsets.
Todd
|
|
|
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 02 Jun 06 12:58 PM
|
cheap abortion pill kit online buy abortion pill fiogf49gjkf0d <
myDate = '2006-05-30 00.00.00' as opposed to WHERE StartDate > '2006-05-30'
>
P.S. - I'm guessing this is just a typo since you use the ISODateTimeString( ) function you posted about.
Note that the flavor of ISO datetime string that SLX requires should not have any dashes and shoudl not include milliseconds on the time portion. Even if you see these execute without error, they are likely to result in a failure on the recieving side of synchronization.
Todd
|
|
|
|
Re: Another GMT Question ?! datetimetype = 'z'
Posted: 02 Jun 06 1:31 PM
|
over the counter albuterol inhaler albuterol otc fiogf49gjkf0d oooooo! :0
Thanks for the info! Disaster averted, Disaster Averted. Please remain seated. (It's Friday, what can I say?...) |
|
|
|