Top Navision "gotchas" for Java/C++ developers

Miklos_HollenderMiklos_Hollender Member Posts: 1,598
edited 2006-08-03 in General Chat
Maybe it could be a good idea to collect those features and customs in Navision that can be hard to understand for Java/C++ developers, because I'm a bit tired of replying e-mails.

1. Forms, Tables, Reports etc. can be considered more or less object classes that inherit for base form, table etc. class. Form, Report etc. variables can be considered as instances. There is no Table variable, it's called Record variable. There is no further inheritance. Also forget polymorphism. However, encapsulation is nice, Record variables work more or less the same you'd expect any object-oriented Java or whatever database API to work.

2. Reading and writing data can be achieved through Record variables (instances of Table class). Forget SQL, it's much more like an Object-Relational Mapper where you access data with methods and fields as attributes. Look up SETCURRENTKEY, SETRANGE, SETFILTER, GET, FIND, NEXT, INSERT, MODIFY, VALIDATE methods in the help.

3. Global variables are actually private variables of the object. Possibly this is the ugliest mis-terminology in Navision.

4. The VALIDATE method of the Record variable (in other words, an instance method of the Table class) is not only used for validating, but also for entering and updating data: RecVar.VALIDATE(newvalue); and then RecVar.INSERT(TRUE) or MODIFY(TRUE); - almost always write data this way.

5. The only variables (instances) that can persist between different calls (different transactions, different users) without saving data to the database are Codeunits with SingleInstance = Yes. These are mostly used for listeners for messages from external applications.

6. As Navision is a thick client application, it's safest to write code that closely emulates what the user does on the user interface. For example, inserting a Sales Header is easier if you only fill the primary key fields except for the No., insert it then validate the other fields and modify it, because this is what the user does on the user interface, and therefore all the OnInsert and OnValidate code in the table is tuned for this behaviour.

More ideas are welcome.

Comments

  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    1. OOP consists of inheritance, polymorphism and encapsulation. Of these three, encapsulation DOES exist.

    2. "accessible from other methods within object" - exactly this is the definition of "private" in OOP terminology.

    4. Huh? Ah... you mean VALIDATE triggers some code somewhere else that fires a COMMIT? Never happened that with me in 3 years, but yeah, theoretically possible... just very rare.

    5. Yeah, OK, it's only unique by users. About transactions, what I mean is it persists between two user-triggered events. Also between transactions, but "user-triggered event" is a broader scale, I agree.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    Ah, I see. Yes. That happens sometimes. Well, I think the main thing which OnValidates are for is to populate like Something Description when Something No. is entered a value - in the same table. I think it's completely safe. Yes, updating other tables can cause such problems, although I never really tried that - that somehow always felt unnatural.
Sign In or Register to comment.