Plugin Export to SQL Bug?

[pricerc]

(7.2)
Just been using to generate a script to send to customer - it looks like it isn't escaping single quotes embedded in the description field.

I haven't checked any of the other fields.

[Mike.Sheen]

Hmmm... I can't reproduce that.

In the plugin "Allow Notes in Purchase Orders To Always Be Editable" which is in demo data - there is a line:

Code: Select all

         //Lock the last rows' bin button

And when exported to SQL it shows up as:

Code: Select all

         //Lock the last rows'' bin button

And the script in entirety is valid and escaped correctly.

Are you able to give me an example plugin which exhibits this issue?

[pricerc]

It's one of my own.

I've changed the single quote to a 'right single quote' (ASCII 92), and then I don't have a problem.

But it's the *description* field that has a problem, not the *code* field.

[Scott.Pearce]

OK, I was able to reproduce. Logged as DEV-7280.

https://service.jiwa.com.au/browse/DEV-7280

[pricerc]

As it turns out, I had to get even more clever.

I was trying to send updates via the XML export, but it wasn't being terribly successful. Unfortunately I'm not on-site, and don't have remote access, so I have no clue about what's going on, except that the customer seems to have old versions of the plugins, even though he's just loaded a new one from XML.

The export to SQL looked promising (and I'm still using it, with a plugin to export them all and then concatenate the files into one big one). But I wanted to be able to *UPDATE* the customer's plugins.

So I've copied them all out into a 'Plugin Backup' SQL database (with no tables but the active plugins and related custom field definitions), and have written a 'restore' procedure that uses MERGE statements to update the plugins back into the Jiwa database.

Of course there are *many* tables linking into SY_Plugin and Co., so scripting an extract of everything was a minor challenge. I'm still not sure I've got everything.

So if I could make a suggestion around this, it would be to switch out the 'INSERT' statements in the Export to SQL to 'MERGE' statements. It would probably then be a bit more useful as a distribution tool.

so instead of:

Code: Select all

INSERT INTO SY_PluginForm (RecID, SY_Plugin_RecID, SY_Forms_ClassName, ItemNo)
SELECT '81bffad2-4d7e-45e1-8706-82d69732805d', (
      SELECT RecID
      FROM SY_Plugin
      WHERE Name = 'Some Cool Plugin'
      ), 'JiwaFinancials.Jiwa.JiwaPluginMaintenanceUI.frmMain', 1;


you have

Code: Select all

MERGE SY_PluginForm TARGET
USING (
   SELECT '81bffad2-4d7e-45e1-8706-82d69732805d' AS RecID, (
         SELECT RecID
         FROM SY_Plugin
         WHERE Name = 'Some Cool Plugin'
         ) AS SY_Plugin_RecID, 'JiwaFinancials.Jiwa.JiwaPluginMaintenanceUI.frmMain' AS SY_Forms_ClassName, 1 AS ItemNo
   ) SOURCE
   ON TARGET.RecID = Source.RecID
WHEN NOT MATCHED
   THEN
      INSERT (RecID, SY_Plugin_RecID, SY_Forms_ClassName, ItemNo)
      VALUES (RecID, SY_Plugin_RecID, SY_Forms_ClassName, ItemNo)
WHEN MATCHED
   AND NOT (
      target.SY_Plugin_RecID = source.SY_Plugin_RecID
      AND target.SY_Forms_ClassName = source.SY_Forms_ClassName
      AND target.ItemNo = source.ItemNo
      )
   THEN
      UPDATE
      SET target.SY_Plugin_RecID = source.SY_Plugin_RecID, target.SY_Forms_ClassName = source.SY_Forms_ClassName, target.ItemNo = source.ItemNo;


It looks worse than it is to code (most because of the really arcane ANSI SQL constructs).

[Mike.Sheen]

But it's the *description* field that has a problem, not the *code* field.

Ahhh... yes I see you stated that in your original post - my bad.