Option to apply workaround for BINARY XMLTYPE in the Editor?

Hi Quest,

as the problem described in Access violation at address 000007FEC897C8BA in module ‘oraclient12.dll’. Read of address 0000000000000010 does break the very user friendly feature of an “edit query” (that shortcut syntax for select tbl.rowid,… from table tbl)), I wondered if it is at all possible to safely select such columns automatically in the editor. As in altering a given statement before sending it to the OCI dll, like the Data tab in SB does. You would need to know, that e.g. a “select * from sometablewithxmltype” will query a binary xmltype column at query runtime, though. I know that it would be resource intensive and somewhat slow, but maybe you already parse the data dictionary anyway and could use that information to identify and rewrite these queries?! Editing XMLTYPE columns directly via OCI is currently not possible anyway, so it would just be nice if Toad would at least not provoke the exception in the OCI dll.

Thanks and cheers,
Julian

Excellent idea. This is done for next beta. We’ll select these columns as CLOBs and they will be read only, same as in Schema Browser. Thanks to @mstaszew for the assist.

It’s not really resource intensive. I doubt if you’ll notice any delay.

Hi John,

this is really great news. Thanks a bunch :slight_smile:

I did not know if you already have all the information needed in the Editor, so I assumed it could get somehow expensive. But yeah, even better if it does not impact performance at all.

I’ll be happy to test it once the feature hits beta.

Cheers,
Julian

Well, we didn’t have all the info…I did have to add a call to the OCI to describe a “select *” on the table, then I could look at the columns and build the SQL. The additional delay is less than 1/4 second for most people, maybe a little longer on a slow network.

doing something like this to all queries in the editor is where this becomes a bad idea (IMHO) because it could get messy with joins, subqueries, derived columns, etc. But for “edit”, it was simple enough.

Ah, I see. Applying this to all queries / tables in it was exactly my thought when I mentioned the performance impact. And I agree, this sounds like the best possible solution.

yeah, unfortunately, we have to modify the actual query so Toad receives a CLOB instead of XMLTYPE. We can’t just handle XMLTYPE as CLOB after it rolls in.

Hi John,

found some time to test the feature. “Edit-Select” of one row works fine. “Edit-Select” of 188 rows works fine. This is even a lot faster then selecting “ordinary” (CLOB) XMLTYPE columns (subjectively) and has XML-highlighting on top. 100% satisfied customer here :wink:

Thanks and greetings,
Julian

Great! Thanks for the follow up.

Hi @JohnDorlon,

I would like to make a follow-up request: Can you guys "xmlserialize-indent" the XMLTYPE when converting it to CLOB, i.e. xmlserialize(document <col> as clob indent)? That would spare one the time to copy the contents of the column to an external editor and pretty-print it there. xmlserialize is not always available and had some bugs in earlier versions of the DB, iirc. Maybe you could make a new option for the behaviour?!

Anyways, would be great if this is possible.

Thanks and greetings,
Julian

This isn't the first time XMLSERIALIZE has been suggested. I'll add it to the list.

1 Like

This was added a while ago, I forgot to update this thread. It's in the current 13.2 beta under Options->Data Grids->Data.

1 Like