Sage 100

Problem with the UDF Limit on a Table: We added 2 UDF'S to the PO_PurchaseOrder Wrk table each one being 8,000 bytes, we got an error when adding the second one and later deleted both and tried to put them back on. But now even if we delete all UDF's when we go in to add a new UDF, the top of the screen shows bytes used of 8,000 (even when there are no UDF's.) These UDF's are needed to pull from 2 PO Header UDF's but now we can't add them back because with the ""Phantom"" 8000 characters that we start with, it will exceed the 20,000 byte maximum. Does anyone know where this ""used bytes"" is stored or calculated from? I've poked around in Data file display and maintenance and I don't see anything in the MAS_System tables that seems to be holding those 8,000 bytes hostage. I've looked at CM_UDF and for this table I only see the actual UDF's and bytes that truly exist. I'm out of ideas for now so any new ideas might help :)

A phantom value is actually found in every WRK table. I believe it represents the number of bytes the standard fields occupy in it. E.g If you look in SO Sales Order Wrk you'll see even more used w/o consideration to UDFs whereas other WRK tables have less. Now I don't know the reasoning behind this (and if it's rational / valid) but later I will take a look to see where the number is coming from.

It's coming from the dictionary. It's adding up the length of all the standard fields. And this is true for any table not just WRK ones. I think the way to deal with your issue would be instead of trying to append to PO_PurchaseOrderWrk, in the Crystal PO form itself just link the worktable to PO_PurchaseOrderHeader and pull in the 2 fields that way.

Thanks Alnoor!, I guess I had never noticed that, I had already linked in the PO header thinking that was a short term workaround. I guess it is a permanent solution instead of a workaround. I like to keep the UDF'S in the worktable especially on things like invoice printing so it is sourced properly whether printed from data entry or history. Luckily this worktable is not accessed by any history printing. This was a good learning experience - before adding large UDF's to the data entry tables - make sure the WRK tables can handle them too :)

Kudos to @AlnoorCassim