jwcolby
jwcolby at colbyconsulting.com
Wed Jun 6 07:01:37 CDT 2012
Gustav, > "Stopped all that"? I do so little Access these days and even less Access with SQL Server that I really don't keep current on it. Because my framework is "bound" it can drill down to discover the data type of every control on a (bound) form. I then built stuff in the framework (years ago) to "standardize" handling dates by inserting a fixed format string (for display) and input mask (for data entry). All of that is automatic unless I over-ride it, which can be nice since I can apply a standard to every form that the framework manages for me without having to find and fix these properties manually. Thus part of my problem was that I used the time(7) date type in SQL Server, but even after fixing that by moving back to the DateTime in SQL Server my framework was still applying a *date* format and data entry string to the controls on these forms. I had placed the format and input masks I wanted in the control properties but the framework was helpfully "standardizing" them for me back to "date". Once I told the framework not to do that the problem was solved. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/6/2012 7:48 AM, Gustav Brock wrote: > Hi John > > "Stopped all that"? > So now you handle your date values as strings? Oh my ... > > And a "time() format" ... what is that? > > Unless you need the submillisecond resolution SQL Server data type DateTime2 offers, all you need is to change the data type (not a format) of the field in SQL Server to good old DateTime. Then your framework will run unmodified. > > It was Feb. 17th you fought with this the last time. > > /gustav >