3 Replies Latest reply: May 15, 2014 10:15 AM by Grant Perkins RSS

    Overflow error when exporting to Access

    Timtropolis _

      Greetings all,

       

      I'm getting an odd error that I can't explain or trap.  I'm using Monarch 11.3 and Access 2003.

       

      I have a report as a source which contains 10 fields.  3 fields are Char, 1 date, 6 numeric.  I set my table in Access to the same field names, sizes and data types.  When I do the export from Monarch, I get an "Overflow" error.   My first thought was the date field so I changed the date field to character in the .xmod and did the same for the Access table.  Again , same error.  I then change all fields to character data type and adjusted the Access table as well with respect to data type and field lengths.  Again, same error.

       

      Now here's the odd part.  If I export this out as a .csv file, it works fine.  I can then import that file into my Access table with no issues.  I'd rather not go this route but its what I have to do for now.

       

      Does anyone have any ideas?  I've also re-created the .xmod file but am still getting the same issue.  I don't believe there are any embedded characters in the source file as I think that would effect the export to .csv.

       

      If anyone can shed some light on this, it would be greatly appreciated.

       

      Regards (and TIA)

      Tim

        • Overflow error when exporting to Access
          Grant Perkins

          What are you exporting to Access? Report, Table, Summary?

           

          I seem to recall from a long time back having some problems with text files that had no end of file marker recognised and some with, in effect, missing end of record markers but I thknk that just caused problems with creating the table in the first place. All a bit specific and distant in my memory.

           

          Hvae you run a validate session on the model to see if anything is reported? A long shot of course but in the absence of anything else at this point you never know what ideas it might throw out.

           

          However it sounds more like a data field anomaly ... maybe. Try with one record and see if that gives the same error. Use several records in case some work and some don't. Not sure what else to suggest at the moment.

           

          Grant

            • Overflow error when exporting to Access
              Timtropolis _

              My apologies for not responding sooner. I was pulled off this project and put onto another.

               

              Grant:

              I tried all of your suggestions with no luck.  To answer your question, I am bringing a report into Access.  I did notice one thing and it has to do with a date field I'm bringing in.  In the report, the field is shows as Short Date (mm/dd/yyyy).  The associated xmod is also defined as short date.  However, I noticed when dumping this out to a .csv file, the date is coming in as yyyymmdd.  I'm assuming that the default format for shortdate in Monarch is this?  if so, is there any way to change this?

               

              TIA,

              Tim

                • Overflow error when exporting to Access
                  Grant Perkins

                  Hi Tim,

                   

                  Dates, hmm.

                   

                  The concept of dates is that they are held in a "standard" format behind the scenes but are formatted in various ways for display and reporting. The standard would typically be yyyy/mm/dd and then some hours, mins and seconds stuff. Or a totally different format of presenting date (Julian for example) in some systems.

                   

                  Taking a 'printed' report into access, rather than a table generated from a report, could be interesting ... or should I read it that you are 'monarching' a report for ingestion into an access based database as data fields?

                   

                  It's sort of tricky to try and advise from afar without access to the target database which, in theory at least, should be simply taking the input and reverse engineering it to how it wants to store things.

                   

                  If you think the date is the problem do you have access to the Access definition with a view to discovering what it is expecting?

                   

                  Grant