By Andria Jensen - 4/19/2007
I have a BO which has a date field. Previously, it was a SmallDateTime field in the database. I started getting an error when trying to put a value of 01/01/1800 in it for a null, so I changed the type to be a DateTime to make it accept the value. I rebuilt the partial BO, and recompiled. I am still getting an exception saying that there is a SmallDateTime overflow exception. I can put the 01/01/1800 date in if I do it directly through Query Analyzer, but when I do it through the BO it still thinks the field is a SmallDateTime for some reason. It's like it isn't recognizing the type change, but all I see on the type in the BO code is System.DateTime. Is there something I'm missing here or something I'm not doing?The exception is coming from the SaveByForm routine in BusinessLayer.vb and it reads as follows: SqlDbType.SmallDateTime overflow. Value '01/01/1800 00:00:00' is out of range. Must be between 1/1/1900 12:00:00 AM and 6/6/2079 11:59:59 PM.
|
By Trent L. Taylor - 4/19/2007
Have you tried turing on the DAL debugger to see the update command? In the AppMain you can set the debug mode for the data source:Databasics.DataSources(0).SetDebugOn("C:\MyDebug.html",True) You can then review the debug information to see if there is anything that gives you a clue. The error is more than likely coming from the SQL side rather than within the BO or DAL.
|
By Andria Jensen - 4/19/2007
Yes, my app is setup to log sql for each time the application is run. However, when I looked at it there was no SQL in the log for the time that the save operation was done...or for the time that the error occured. It appears as though the error is before the SQL is even tried...
|
By StrataFrame Team - 4/19/2007
Have you opened up the database with SQL Server Management Studio to see if the type was properly converted and saved? The data type in the database would have to still be a SmallDateTime as the BO and DAL are ignorant to the SmallDateTime and use an internal DateTime for any date value. So it would have to be on the SQL side.
|
By Andria Jensen - 4/19/2007
I did verify that the type was changed to a regular DateTime in Enterprise Manager. I have also been able to run a sql update statement through query analyzer to set the date to be 01/01/1800 and it works correctly. I didn't think the BO knew anything about SmallDateTime, but I'm just not sure where to look anymore.
|
By Andria Jensen - 4/19/2007
Also, if this were a sql error wouldn't there be an entry in the sql debug log? In the sql log I have it doesn't have any sql for the event I'm getting the error message on.
|
By Trent L. Taylor - 4/19/2007
Have you built the framework in debug mode and see where the point of failure is through a debug session? The BO really doesn't know about the SmallDateTIme. So without being in your seat and performing a debug, there is no way for me to give you a direct answer here.
|
By Andria Jensen - 4/19/2007
Ok, I'm trying to step throught the code and figure out what's going on here. I am seeing something that looks a little suspicious and mayb eyou can explain it. In the DataLayer.vb code inside the BuildInsertInfo function I am stepping through where it is building the QueryInformation object. There are a few lines towards the end that set some 'misc properties'. One of these is loInfo.FieldNativeDbTypes = Me._BusinessObject.FieldNativeDbTypes. When I inspect the contents of these, all of my fields that are normal DateTime types have a value of 4. However, the field in question has a value of 15. I am assuming this is a SmallDateTime. Where is the business object getting these types from and could this somehow be affecting what's going on here?Also...if this problem would be more quickly solved via a look at my computer, I can set that up if necessary.
|
By Andria Jensen - 4/19/2007
OK, I think I've found the issue. In the designer code of the BO, inside the New()...there is a block of FieldNativeDbTypes.Add methods for each field. The field in question still has this line of code:_FieldNativeDbTypes.Add( "InsurerExpire", System.Data.SqlDbType.SmallDateTime)I think this may be a bug because it should be changing that back to DateTime if I rebuild the partial shouldn't it?
|
By Trent L. Taylor - 4/19/2007
I think this may be a bug because it should be changing that back to DateTime if I rebuild the partial shouldn't it? Hmmm...yes you are correct. I will have to look into this. If you remove that field descriptor class and rebuild the partial, does it show back up correctly? Or, if you just change it to represent a DateTime and rebuild the partial does it leave it alone? In either case, I am glad you found your problem. I will look into this from a BO Mapper perspective.
|
By Andria Jensen - 4/20/2007
No, I changed it to a DateTime in the designer line but it changed back to a SmallDateTime when I rebuilt the partial. For whatever reason it just won't let go of that original SmallDateTime type. Let me know what you find out...hopefully I can get a fix for this so I can continue working on this piece of code. Thanks for the help!
|
By StrataFrame Team - 4/23/2007
OK, I've been looking through the code that generates the partial classes for business objects, and the only SQL data type that uses SmallDateTime is SmallDateTime. So, it could be that your business object is mapped in the BOMapper to a DDT profile rather than the actual SQL Server and the field is still SmallDateTime in the DDT. Or vice versa, it's mapped to SQL Server and the actual field's data type wasn't changed. If the actual source of the column is properly set to SmallDateTime, then there must be a problem with the GetSchema() method of the SQL Server connection returning the proper value.
|
By Andria Jensen - 4/23/2007
Ok, for some reason you made me think of what I was doing wrong here. We have LOTS of databases that we use, and I was simply looking at the one I was running with and not the one I was mapping to. I kept changing it in the one I was running with, so of course when I stepped through code it was changed. But, the BO Mapper was still getting the SmallDateTime because I hadn't changed it in the mapped db. Now I feel dumb...haha. Sorry for the false alarm, but thanks for helping me through it.
|
By StrataFrame Team - 4/24/2007
No problem  We do that all the time. In fact, Steve and I were working on one yesterday and kept getting an error sayind that field such-and-such wasn't part of the table... ??? Well, as it turns out, we had just that morning moved our connection string over to a different database that contained some test data. Spent well over an hour stepping through the code thinking there was a bug
|