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

    Error Reading Table

    ARICE01 _

      I am a Monarch 9 User and am having problems reading a Table via the OLEDB Connection.  When selecting the Table it give me the following error: An error was encountered reading the sample data. The value in row 1, column 19 could not be read. This and subsequent bad values will be treated as nulls.

       

      The actual field contains "Description" or "Comments" and has a long record length.  Any ideas how I can overcome this error and get the field values to come through?  I have no opportunity to edit/mask the source file.  Thanks in advance for a prompt reply

        • Error Reading Table
          Grant Perkins

          Hi Arice01 and welcome to the forum.

           

          When I have seen this in the past it has normally related to Monarch assessing the first 250 rows of input and concluding that it was really dealing with a numeric field but some records were filled with characters. Like row 1 being a title row for example but the import routine not having been set up to identify it as a title row. Sounds like this is not the obvious case for you. What does Monarch think it is reading from column 19?

           

           

          Grant

            • Error Reading Table
              ARICE01 _

              Hi Arice01 and welcome to the forum.

               

              When I have seen this in the past it has normally related to Monarch assessing the first 250 rows of input and concluding that it was really dealing with a numeric field but some records were filled with characters. Like row 1 being a title row for example but the import routine not having been set up to identify it as a title row. Sounds like this is not the obvious case for you. What does Monarch think it is reading from column 19?

               

               

              Grant[/QUOTE]

              I know that the field values contains text and numbers as it is a "Description" field describing details of expenses incurred by consultants. For example: "This $200 expense is for meals with 5 members of my project team". Monarch is obviously picking up the fieldname "Description" correctly, but for some reason if treats the content of every record as null.  I believe if I try the ODBC connection it works fine, but is extremely slow reading the Table.  The OLEDB connection is much faster.

                • Error Reading Table
                  Grant Perkins

                  Definitely suggests to me that Monarch has interpreted the field (on balance of pre-analysis or maybe via the translation file somehow?) as being a numeric field. If the first 250 line were pretty much all numeric or blank that might happen I suppose.

                   

                  I will have a dig around an see if I can come up with something to experiment on - someone else may get back here with their solution first.

                   

                   

                  Grant

                    • Error Reading Table
                      ARICE01 _

                      I have done further eva;uation by reading the SQL table using both the ODBC Connection and OLEDB Connection and found the OLEDB connection option to be much faster.  However, I experience data lost resulting from the following warning for a critical, alpha-numeric data field (field= Description).

                       

                      “An error was encountered while reading the sample data. The value at row , column could not be read. This and subsequent bad values will be treated as nulls.”

                       

                      I called Datawatch Tech Support and they suggested no good solution other than staying with the  ODBC connection.  Does anyone have a good solution for this?  I am anxious to crack this data problem, while gaining the efficiency of the OLEDB connection.

                        • Error Reading Table
                          Grant Perkins

                          I have yet to find anything I can sensibly use to experiment with this.

                           

                          Have you been able to identify what is different in the data fields that go missing compared to the ones that are retrieved successfully? Or maybe something specific in the ODBC definitions that prevents the anomaly?

                           

                           

                          Grant