Home
|
Forums
|
Contact
|
Search
|
Syndication
[login]
[create account]
Tuesday, November 26, 2024
slxdeveloper.com
Home
Search
Contact us
About slxdeveloper
Syndication
Community
Forums
(NEW!)
Newsletter Archive
Members
Your Profile
Submit Article
General
Administration
(6)
OLE DB Provider
Miscellaneous
(2)
Architect
VBScript
(9)
ActiveX Controls
(6)
How To's
(14)
.NET Extensions
(3)
External
OLE DB Provider
(12)
SLAPI (SlgxApi.dll)
SalesLogix COM
(1)
Web
ASP/ASP.NET
(2)
Web Services
Web Client
Downloads
Samples
(17)
Documentation
(7)
Utilities
(18)
Resources
SalesLogix
(3)
Programming
(1)
11/26/2024 8:26:09 AM
slxdeveloper.com Community Forums
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!
External Development Forums - SalesLogix OLEDB Provider
Forum to discuss using the SalesLogix OLE DB Provider from external applications (including usage of built-in provider procedures). View the
code of conduct
for posting guidelines.
Forums RSS Feed
Back to Forum List
|
Back to SalesLogix OLEDB Provider
|
New Thread
View:
Dynamic
Flat
Tree
Search:
Author
Thread: SecTableDefs.DateTimeType = 'D' Issue
Lane
Posts: 121
SecTableDefs.DateTimeType = 'D' Issue
Posted: 05 Oct 07 12:44 PM
I've Upgrade a database and converted datetime fields to Date fields or in other cases define a data table with a “Date” field. The "Date" field type blocks localization of the time stamp keeping dates from changing between users in the USA.
I then generate a SQL View and reference this/these fields. This could be for a report to provide union capabilities. The View then needs to be ENABLED in DB Manager.
Now the fields WILL shift for local time since the new views SecTableDefs.DateTimeType field are null.
I update the specific Date fields in SecTableDefs = "D" and here is problem 1)
1) The Provider Service Server has to be rebooted to rebuild the providers SecTableDefs cache. I assume a slx stored procedure exists to perform this operation and it is required for installations with mission critical applications coexisting on the server. However at this time I've tried all I've been able to locate and none have worked. Stopping the service does nothing.
Once a reboot is complete, the date field “sometimes” still continues to shift causing inconsistencies in reports. This is problem 2).
We have not been able to discover anyway to identify why one field works and the next does not. I do not believe table name or column name case is involved but we can force all names to upper case if this is a requirement, it does not appear to be.
Any assistance in solving either of these would be greatly appreciated.
[
Reply
][
Quote
]
Ted Sturr
Posts: 78
Re: SecTableDefs.DateTimeType = 'D' Issue
Posted: 05 Oct 07 3:41 PM
I will start by saying I feel your pain. Unfortunately I do not have an answer for you, except that I do think this is a bug with the provider. I think that SLX is aware of this bug and a fix is supposed to be eventually coming out. We have experienced numerous issues with this exact same scenario. If you find anything new please post back, or if we discover anything we will do the same. When integrating with outside systems the "great idea" of GMT dates really becomes far too troublesome.
Ted
[
Reply
][
Quote
]
Lane
Posts: 121
Re: SecTableDefs.DateTimeType = 'D' Issue
Posted: 05 Oct 07 4:03 PM
Thanks, misery loves company !
Have you found a way to get the provider to reload the cache short of a reboot?
[
Reply
][
Quote
]
Page 1 of 1
You can subscribe to receive a daily forum digest in your
user profile
. View the site
code of conduct
for posting guidelines.
Forum RSS Feed
-
Subscribe to the forum RSS feed to keep on top of the latest forum activity!
slxdeveloper.com is brought to you courtesy of
Ryan Farley
&
Customer FX Corporation
.
This site, and all contents herein, are Copyright © 2024 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.
code of conduct
|
page cache (param): 11/26/2024 8:34:03 AM