• Replies 4 replies
  • Subscribers 337 subscribers
  • Views 141 views
  • Users 0 members are here
Related

Local System Table Column Issue

John A. Moskal II
$organization

Hello!

It has been a while since I created a new post myself, so here goes!

I am trying to create a new local system table, of which I have done dozens of times before, however I am getting a fun new error.  The table is all set up in system tables just fine, however when I go to add a row, I get the error here:

"Last Error: DataWindow column type does not match GetItem type at line 7 in function of_get_nextid of object w_ref_tbl."

The table I am trying to create is pretty basic:

  • Name (for someone to type in a name) - Varchar (40)
  • Userid (Tessitura username) - Char (8), referencing T_METUSER, description and value columns just using userid
  • Organization (Resident Company organization - INT, referencing TR_ORGANIZATION, description = description, value = id, where id > 0
  • The 5 standard created by, create date, create location, last updated by, last updated date

UP_POPULATE_REFERENCE_METADATA run just fine, updates in REFERENCE tables done.  The only issue is in trying to add a column in Tessitura.  I inserted one row via the database, worked just fine in the database, and everything looks good in Tessitura.  I can edit the three columns, type anything in the name column, and choose whatever I want from the two dropdown columns which are pulling the correct information, save triggers for the last updates working just fine.  But I still cannot add a new row without pulling that error.  I in fact have multiple other local system tables set up using these exact columns, and they all work just fine.  The only difference is that this one does not have an ID/Identity column, but there are plenty of system tables that do not have one of those.

Anyone got any ideas?

Thanks,

John

Parents
  • $organization

    Troy's right - the id column is required- "The primary key for a local table must be an integer (tinyint, smallint, or bigint may be used as well) and be named ‘id’"

    Martin

  • $organization in reply to Martin Keen (Past Member)

    I tried that, and it appears to have solved the issue.

    However, while this particular table is neither particularly helped nor hindered by the presence of an ID column, I have created numerous local system tables in the past that do NOT have an ID column.  Anyone have an idea as to why this one requires it when others have not?

    For example, we are a consortium environment, but our Box Office services all performances on our campus, and thus have access to all organizations' public control groups (e.g., not Development stuff, but all the ticketing stuff).  So I created a table linking together control groups and organizations, so that they can easily pull large amounts of data specific to one organization by just running the report against that organization rather than having to select all the individual seasons, campaigns, etc... that are specific to that organization.  Anyway, that system table has just two columns, Control Group and Organization.  No ID column.  And it still works just fine.

    As I said, it does not particularly matter in this case, but my experience was that it was not necessary.  So, has something changed?  I have seen the exact line you quote in the documentation, Martin.  But I did not see a line in there where it said "every table MUST have a primary key".  Just that those were the specifics for a primary key were there one to be had.  In case it matters, we are on Version 14.1.7.

    John

Reply
  • $organization in reply to Martin Keen (Past Member)

    I tried that, and it appears to have solved the issue.

    However, while this particular table is neither particularly helped nor hindered by the presence of an ID column, I have created numerous local system tables in the past that do NOT have an ID column.  Anyone have an idea as to why this one requires it when others have not?

    For example, we are a consortium environment, but our Box Office services all performances on our campus, and thus have access to all organizations' public control groups (e.g., not Development stuff, but all the ticketing stuff).  So I created a table linking together control groups and organizations, so that they can easily pull large amounts of data specific to one organization by just running the report against that organization rather than having to select all the individual seasons, campaigns, etc... that are specific to that organization.  Anyway, that system table has just two columns, Control Group and Organization.  No ID column.  And it still works just fine.

    As I said, it does not particularly matter in this case, but my experience was that it was not necessary.  So, has something changed?  I have seen the exact line you quote in the documentation, Martin.  But I did not see a line in there where it said "every table MUST have a primary key".  Just that those were the specifics for a primary key were there one to be had.  In case it matters, we are on Version 14.1.7.

    John

Children
  • $organization in reply to John A. Moskal II
    John A. Moskal II said:
    Anyone have an idea as to why this one requires it when others have not?

    It's always a little mysterious, but with new versions of Tessitura (usually new major versions) the rules for such things seem to tighten up, and sometimes cause issues with custom tables, especially ones that interact with custom InfoMaker tabs. It's been a while, but I think I had a few id column-less custom tables, too, until one day IM tabs suddenly rejected them.