It can only mean that 1) it was not created from Navision, but from SQL 2) or Navision sh**ted itself during creating the table and didn't really finish creating it. I'd suggest to create that table again.
Do It Yourself is they key. Standard code might work - your code surely works.
Please forget that as fast as you can Navision's logic is so different from SQL (it's a deeply modified RAIMA engine from somewhere the eighties) that I consider it a complete miracle that they could create an SQL database option. Just look at an oninsert sql trigger on any "entry" table if you like to read horror stories So, the relation between Navision and SQL is so complicated that it is very important that do not modify anything from SQL. (Reading it from is SQL is OK except that option fields show up as 0,1,2...)
Do It Yourself is they key. Standard code might work - your code surely works.
Navision treats SQL Server pretty much as a back end only. Maintaining the object is all done from the Navision IDE. The only thing you would typically do in a Navision implementation on SQL Server is maintain the database, work on maintenance plans, do backups, things like that.
In rare occasions you'd use SQL Server views, but even then you'd be linking those to Navision table objects from the Navision IDE.
Forget about using SQL Server for any 'real' business logic.
Comments
Do It Yourself is they key. Standard code might work - your code surely works.
Do It Yourself is they key. Standard code might work - your code surely works.
Navision treats SQL Server pretty much as a back end only. Maintaining the object is all done from the Navision IDE. The only thing you would typically do in a Navision implementation on SQL Server is maintain the database, work on maintenance plans, do backups, things like that.
In rare occasions you'd use SQL Server views, but even then you'd be linking those to Navision table objects from the Navision IDE.
Forget about using SQL Server for any 'real' business logic.
RIS Plus, LLC