Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 310 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Top Navision "gotchas" for Java/C++ developers
Miklos_Hollender
Member Posts: 1,598
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.
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.
0
Comments
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.