Table %1 does not exist in document

.rpt Inspector Online - Public Beta bug
1

.rpt Inspector Online Broker Version:
major.minor.revision

0.6.7
convert enabled

Please tell us about your environment where the Broker is running:

  • Operating System:
    Windows [7|8|8.1|10]
    WIndows 8 x 32

  • Is this running in a virtual machine:
    Yes / No

    • If answered yes above, which virtual machine environment and version:

ESXi 6.0
Please tell us about your environment where the Web Browser is running:

  • Operating System:
    Windows [7|8|8.1|10]|Linux (distro and version)|OSX 10.x
    Win 7 X 32

  • Browser kind and version:
    Firefox XX | Chrome XX

Chrome 70

|2008 / 12.x.x|XI R2 / 11.5.x|XI / 11.x.x|10.x.x|9.x.x|8.5.x]

XIR2

Current behavior:

Using the same sample report - it fails to map ODBC to a new value.

This is the message with the fail:
[The table %1 does not exist in the document.] C:\XXX_Environments\2018-09 SF mapping Issue\sample_fixup_problem - ok.rpt

Expected behavior:

Mapping should complete and not error.

2

Please try with both convert driver unchecked and verify database unchecked.

If the report was built using ODBC and your destination is ODBC, then enabling convert driver isn’t necessary. Although the broker is designed to check if the source and destination driver are the same not to try to do a conversion, perhaps something is failing there so we’d like to rule that out by having you uncheck that.

And while having the verify database is a good idea, it’s possible that something is also causing it to return a false positive, so we’d also like to rule that out by having you uncheck that.

3

Running with Convert on and Verify off reported as being successful.

4

And you’ve validated that all is now correct with the report after the change(s)?

Can you email support the report you are testing with (no saved data please) so we can analyze it further on our end?

5

After a lot of research and testing, we have found what we believe to be the cause. When you leave verify enabled and it connects to the destination database tables, if the tables and/or fields are even slightly different from the original, it will trigger a failed validation.

With the next broker version there is a less cryptic message should this happen and we’ll also default the verify to off. Further in the roadmap we’d like to offer a table / field mapping dialog.