Stumped by bizarre license error

DakkonDakkon Member Posts: 192
So I'm trying to import some update objects from my solution center and I get the error:
Your program license does not allow you to create the X field in the Y table.
Contact your system administrator to update your program license.
Now you're probably thinking "well obviously you are using the wrong license", but let me lay this all out. We have a development database, test database and production database. The dev and test databases are on one server and production is on its own. The license file is loaded per server currently. I am a Super in all databases. The file I am importing is your basic fob file of objects.
Here's where it gets strange. I get the error above when attempting to import this fob into our dev database and yet it imports without problem in the test database. So far the solution center is puzzled too and we got the same error when attempting this with their license as well. So ...does anyone have any ideas? So far my solution has been to painstakingly go through and delete each table that is causing problems so that it will create on import. Thankfully I can get away with this in the dev database if I have to but I'd rather find a solution.
Thad Ryker
I traded my sanity for a railgun :mrgreen:

Comments

  • KYDutchieKYDutchie Member Posts: 345
    Hi,

    this error is not as strange as you might think. You obviously have table definition differences between your test and dev environments.
    You usually get this error when you try to add a field outside the custom numbering range (50000..99999) to a native Microsoft table.

    Compare the fields in problem table from in the DEV database with the same table from the test database.
    I think that you are missing a field in the DEV.

    I hope this helps,

    Regards,

    Willy
    Fostering a homeless, abused child is the hardest yet most rewarding thing I have ever done.
  • DakkonDakkon Member Posts: 192
    Oh I'm definitely missing the field, part of the upgraded objects is that those new fields are being added. However given that it's a fob file I wouldn't think the license would matter. Aside from that I am also missing the fields from the test database objects as well but it imports without any errors into that database. The objects in test and dev are exactly the same aside from minor variances where there is a development project in process.
    Thad Ryker
    I traded my sanity for a railgun :mrgreen:
  • DenSterDenSter Member Posts: 8,305
    You can export objects in text format, but give it a name that ends with .fob. Make sure that you are indeed working with an actual fob file.
  • DakkonDakkon Member Posts: 192
    Yeah, that was actually the first idea the solution center had, but alas it is indeed an fob file.
    Thad Ryker
    I traded my sanity for a railgun :mrgreen:
  • vaprogvaprog Member Posts: 1,139
    What type of DBMS are you using?
    If on SQL Server, what security model? Are users fully synchronized?

    If this does not help, try importing with a more priviliged user (SQL Server side).

    Are you replacing or merging the tables?
  • DenSterDenSter Member Posts: 8,305
    Dakkon wrote:
    it is indeed an fob file.
    How did you verify that? Did you just look at the file extension or did you actually open it with notepad?
  • DakkonDakkon Member Posts: 192
    Yeah, well win32pad but basically same kind of thing. I finished importing the objects the hard way in our dev system so I have less pressing need to figure this out, though I'd still love to know what caused such weird behavior.
    Thad Ryker
    I traded my sanity for a railgun :mrgreen:
Sign In or Register to comment.