Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 1. The Basic Ingredients > More Definitions (Related to NAV)

More Definitions (Related to NAV)

The following are a few more definitions related to NAV:

  • Database: This consists of two database definitions (physical and logical). There are two implementations of the physical database (C/SIDE Database Server and Microsoft SQL Server). The C/SIDE Database Server was formerly known as the “Native” database because for number of years, this proprietary server was the only database for NAV. In earlier versions, it did not have a name other than “the NAV (or Navision) Server”. The logical database definition relates to the sum total of the relationships between data, the indexes that control data access, and in NAV, the SumIndexFields and FlowFields (special data summing features, which are explained in detail in a later chapter).

    NAV is a relational database system. The Development Environment (C/SIDE) and tools (C/AL), makes the choice of underlying database (C/SIDE Database Server or Microsoft SQL Server) platform almost transparent to the developer. In this book we will not concern ourselves with the physical database definition because, except in rare circumstances, our development work will not be guided by physical database factors. When you become involved in more complex design activities, you will likely need to be concerned about the differences between the two database options.

  • Properties: These are the attributes of the element (e.g. object, data field, or control) that define some aspect of its behavior or use. For example, display length, font type or size, and if the elements are either editable or viewable.

  • Fields: These are the individual data items.

  • Records: These are group of fields (data items) that are handled as a unit in most Input/Output operations. The table data consists of rows of records and columns consisting of fields.

  • Controls: These are containers for constants and data. The visible displays in reports and forms consist primarily of controls.

  • Triggers: The generic definition is a mechanism that initiates (fires) an action when an event occurs such as reaching a certain time or date or upon receiving some type of input. A trigger generally causes a program routine to be executed. NAV triggers have some similarities to those in SQL, but they are not the same. NAV triggers are locations within the various objects where a developer can place comments or C/AL code. The following are the NAV triggers:

    • Documentation Triggers consist of comments only. Every object type except MenuSuite has a single Documentation trigger.

    • Event Triggers are “fired” when the specified event occurs. Each object type has its own set of predefined triggers. The event trigger name begins with the word “On” such as OnInsert, OnOpenForm, and OnNextRecord.

    • Function Triggers are “functions” that can be defined by the developer. They represent callable routines that can be accessed from other C/AL code either within or outside the object where the called function resides. Many function triggers are provided as part of the standard product. As a developer, you may add your own custom function triggers as needed.

  • License: A data file supplied by Microsoft that allows a specific level of access to specific object number ranges. NAV licenses are very clever constructs, which allow distribution of a complete system, all objects, modules, and features while constraining exactly what is accessible and how it can be accessed. Of course, each license feature allowing access to various objects and system functions, including the ability to do development, has its price. Microsoft Partners have access to licenses to provide support and customization services for their clients. The broadly featured Partner licenses are often referred to as a developer’s license, but end-user firms can also purchase licenses allowing them developer access to NAV.

  • Object numbers and field numbers: The object numbers from 1 (one) to 50,000 and in the 99,000,000 (i.e. 99 million) range are reserved for use by NAV as part of the base product. Objects in this number range can be modified or deleted, but not created with a developer’s license. Field numbers are often assigned in ranges matching the related object numbers (i.e. starting with 1 fields relating to objects numbered 1 to 50,000, starting with 99,000,000 for fields in objects in the 99,000,000 and up number range).

    Object and field numbers from 50,001 to 99,999 are generally available to the rest of us for assignment as part of an ad hoc customization developed in the field using a normal development license. But object numbers from 90,000 to 99,999 should not be used for permanent objects as those numbers are often used in training materials. Microsoft allocates other ranges of object and field numbers to ISV (Independent Software Vendor) developers for their add-on enhancements. Some of these (in the 14,000,000 range in North America, other ranges for other geographic regions) can be accessed, modified, or deleted but not created, using a normal development license. Others (such as in the 37,000,000 range) can be executed but not viewed or modified with a typical development license. The following table summarizes the content as:

    Object Number RangeUsage
    1 – 9,999Base application objects
    10,000 – 49,999Country-specific objects
    50,000 – 99,999Customer-specific objects
    100,000 – 99,999,999Partner-created objects


  • Work Date: This is a date controlled by the operator that is used as the default date for many transaction entries. The System Date is the date recognized by Windows. The work date can be adjusted at any time by the user, is specific to the workstation, and can be set to any point in the future or the past. This is very convenient for procedures such as closing off Sales Order entry for one calendar day at the end of the first shift, then having the Sales Orders entered by the second shift dated to the next calendar day. You can set the work date by selecting Tools|Work Date, and then entering a date.


  

You are currently reading a PREVIEW of this book.

                                                                                                                    

Get instant access to over $1 million worth of books and videos.

  

Start a Free Trial


  
  • Safari Books Online
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint