The fields themselves are set up as normal datetime, which will hold the time. The problem you will run into is if you change the format that is in the database to include the time, you will most likely cause errors and possibly corruption in the table itself.
If you need to have the time added as well, I would add another table to keep up with changes. Then set a trigger on the GP Table to add the information you're looking for. This way you're not making changes to the database that would effect the app's operation.
Great Plains is developed using Dexterity and Dexterity originally supported the Ctree and B-trieve ISAM databases. Both of these databases had separate date and time datatypes. So Dexterity itself was designed with separate date and time datatypes.
When SQL support was added for version 3.10, the date datatype was implemented on SQL as datetime with the time component being 00:00:00. The time datatype was implemented on SQL as datetime with the date component being 01/01/1900.
Even though Dexterity does now have a datetime datatype for COM integration, all the tables use separate date and time and so will have the half empty datetime fields in SQL.
I hope this explains why it works this way.
David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer
MBS Support - Asia Pacific
Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.