Sage 100

 View Only
Expand all | Collapse all

OK, looking at the 911 submission and having just

Wayne Schulz

Wayne Schulz10-11-2012 09:51

Jeff Schwenk

Jeff Schwenk10-11-2012 11:24

  • 1.  OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:49
    OK, looking at the 911 submission and having just got off the phone with someone with the same error - has anyone noticed an uptick in date formatting errors? Usually they appear correct on the the screen, but you get an error when trying to print the invoice or register or whatever and you have to DFDM to see that instead of a zero there is a space in the date, or something else weird. It's like Sage relaxed the checking when saving dates in the last couple of versions or something. I'm getting these about once every 3 weeks now in various modules.


  • 2.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:51
    I've not noticed an uptick


  • 3.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:51
    This date was obviously incorrect. I did not have to through DFDM to find it. It was something like 173019.


  • 4.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:54
    Yeah, once in a while you get lucky and they are obvious. But I've had a lot lately that look fine on the screen and the only way to find them is DFDM. But even so - why is the software accepting a date like that in the first place?


  • 5.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:55
    Can't you also use Crystal - as I recall you have to first fix the ODBC to accept invalid characters - I'm looking for my notes on that..


  • 6.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 09:56
    Well there's always that. If you keyed that date in, I don't think it would accept it so something must have happened afterwards.


  • 7.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:02
    So far I've been lucky and the data entry files are small enough I can quickly scan thru using DFDM. I""m just wondering what is up, but apparently it's only the clients I come in contact with that have the touch. :-(


  • 8.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:04
    I'm pretty sure Jeff Schwenk had this issue a couple of weeks ago too. I remember him saying it looked normal but he rekeyed it and that fixed it, similar to yours.


  • 9.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:10
    Here it is: Go into your SOTAMAS90 ODBC source. Check off ""NULL Date"". Create a report in Crystal that draws from the file with the bad date. The bad date will no longer stop the report from processing. Sort by the date field. The bad dates will sort to the top (or end).


  • 10.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:15
    Interesting @WayneSchulz - are you saying to select the Null Date field, to allow it to bring in invalid dates? Mine is NOT currently selected in ODBC adminstrator.


  • 11.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:19
    Correct. If you do that then when you create a Crystal report it will no longer error out. Without that change you can't create a report because Crystal stops at the bad date.


  • 12.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 10:33
    Cool, learned something new today. Now I can go home....


  • 13.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 11:24
    Bad dates are more frequent these days.


  • 14.  RE: OK, looking at the 911 submission and having just

    Posted 10-11-2012 11:36
    I had the exact same thing hqppen in PO Receip of Goods.