Forum Discussion

VladimirK's avatar
VladimirK
Contributing Partner
4 years ago
Solved

Delete extra field in MYOB Exo

Is there a way to delete an extra field from MYOB Exo table using the Exo Configurator or anything else? 

 

I mean not to remove it from the form only, but also from the table.

 

The reason is that I created the field with a wrong type and now I want to recreate it with another one, using the same name.

EXO
  • Will_H's avatar
    Will_H
    4 years ago

    Hi VladimirK ,

     

    Yeah, just alter the table schema directly.  You might need to refresh a couple of views afterward. (To make sure that the stored definition doesn't screw up if you try to use that view.  There's a stored procedure called something like "RefreshAllViews" (Sorry, guesswork, don't have the screen in front of me.)  Running this view just forces SQL to recache the column lists for the default API views, etc.

     

    For actual tables, I'd always do a quick scan of sys.columns to see which tables the extra field had been automatically added to.  When you use the Extra Field adder in Exo it will add to all the related tables. (For example, with Sales Orders there is also an Archive table.  For DR_TRANS there is also PARK and ARCHIVE).

     

    So take a backup of the DB, alter tables, check you didn't break anything.  If working with an actual client DB, I'd always involve the business partner, because it's a common device for there to be custom triggers involving extra fields. (Again, I've seen some interesting behavior by SQL Server when fields were updated, but not every trigger/view that was using Select * had its cached definition refreshed.).

     

    Regards,

4 Replies

Sort By
Replies have been turned off for this discussion
  • Will_H's avatar
    Will_H
    MYOB Moderator
    4 years ago

    Hi VladimirK ,

    It would be best to talk to your client's Exo Business Partner for assistance with this, as they may have custom processes and data structures in place.

     

    With that said, Exo does not ever drop extra fields automatically once they're added.  You'd need to modify the relevant tables (and potentially views) manually.  I would be very leery of making any data structure changes if you aren't 100% confident in your actions.  The Business Partner is the correct person for those kinds of changes.

    • VladimirK's avatar
      VladimirK
      Contributing Partner
      4 years ago

      Hi Will,

       

      Thanks for your reply.

       

      I don't have a business partner. I'm a developer and I'm just testing stuff on my local Exo demo installation. I tried to replicate the extra field from the database of our Exo client, but I created this extra field with the wrong type. So I just wanted to change it but found that it's not so easy.

       

      I see what you mean though, I need to go into the database itself and delete this field from there directly taking into accounts all the links created.

      • Will_H's avatar
        Will_H
        MYOB Moderator
        4 years ago

        Hi VladimirK ,

         

        Yeah, just alter the table schema directly.  You might need to refresh a couple of views afterward. (To make sure that the stored definition doesn't screw up if you try to use that view.  There's a stored procedure called something like "RefreshAllViews" (Sorry, guesswork, don't have the screen in front of me.)  Running this view just forces SQL to recache the column lists for the default API views, etc.

         

        For actual tables, I'd always do a quick scan of sys.columns to see which tables the extra field had been automatically added to.  When you use the Extra Field adder in Exo it will add to all the related tables. (For example, with Sales Orders there is also an Archive table.  For DR_TRANS there is also PARK and ARCHIVE).

         

        So take a backup of the DB, alter tables, check you didn't break anything.  If working with an actual client DB, I'd always involve the business partner, because it's a common device for there to be custom triggers involving extra fields. (Again, I've seen some interesting behavior by SQL Server when fields were updated, but not every trigger/view that was using Select * had its cached definition refreshed.).

         

        Regards,