Wednesday, July 29, 2009

C/SIDE Concepts

Description of C/SIDE Concepts

Properties
Properties control the appearance and behavior of the application objects and all their sub-objects. Properties are used to control the appearance of data, specify default values, specify colors, and define relationships.

C/AL
C/AL is the language you use to write functions in C/SIDE. In the previous table, "C/AL" refers to functions written in this language.

Triggers
A trigger is a mechanism that is built into an application object. When certain actions are performed on the application object, the trigger initiates an action. You can add your own C/AL code to the trigger to modify the default behavior of the application object or extend its functionality.

Keys
Keys define the order in which data is stored in your tables. You can speed up searches in tables by defining several keys which sort information in different ways.

Fields
A field is the smallest building block in your database. A field typically stores information such as a name or a number.

Controls
Controls are objects on a form or report that display data, perform actions, or enhance the appearance of the form, such as command buttons and text labels.

Request Form
A request form is a form that is used in a report. Before a report is run, a request form is displayed to let the user specify filters and options for the report.

Template
A template defines the overall layout of a report.

Data Items
A data item is a building block for defining a model of your data when you create a report. You use a hierarchy of data items to define which data the report will contain. A data item represents a table, and when you run a report, the system cycles through the records in the associated table. A data item can have one or more sections.

Sections
A section is a substructure of a data item, where you place controls to display information. You will typically use sections that define the body, header, and footer in your report.

Object-Oriented vs. Object-Based

C/SIDE is not object-oriented but object-based. This is an important distinction. In an object-oriented language or environment, a developer can create new types of objects based on the ones already in the system. In Microsoft Dynamics NAV, you can only create objects that are either tables, forms, pages, reports, dataports, XMLports, codeunits, or menu suite objects.Because there are a limited number of application objects, C/SIDE works faster and more efficiently. The greatest benefit is the Stability.

Object Designer

The Object Designer is the main tool for developing C/SIDE applications. This tool allows you to do the following:
. Design new tables, forms, pages, reports, dataports, XMLports, menusuites and codeunits.
. View existing application objects.
. Modify existing application objects.
. Run an application object (with the exception of XMLports, menusuite objects and pages).

Tools in the Object Designer
The following table lists the tools that are available in the Object Designer.

Tool - Designed for

Table Designer - Tables
Form Designer - Forms
Page Designer - Pages
Report Designer - Reports
Dataport Designer - Dataports
XMLport Designer - XMLports
C/AL editor - Codeunits
Navigation Pane Designer - MenuSuite objects

Monday, July 27, 2009

C/SIDE Fundamentals

Here I am giving an Introduction to user interface and to some of the basic concepts that are relevant to application design such as the different object types.
C/SIDE applications are based on certain application objects. They are
Table
You use tables to store data. For example, a business application usually contains a customer table that stores information about each customer.Understanding tables is the key to using all the other objects.
Form
You use forms to access the information that is stored in the tables. You use forms when you enter new information and when you view information that already exists in the database.
Report
You use reports to present information. You use filters and sorting to select the data that you want to present in a report.
Dataport
You use dataports to import data from and export data to external text files.
Codeunit
A codeunit contains user-defined functions written in C/AL code. C/AL is the application language you use to write functions in C/SIDE. The functions that a codeunit contains can be used from the other objects in your application. This helps to minimize application size because the same code can be reused.
MenuSuite
A MenuSuite object contains the set of menus that are displayed in the Navigation Pane.
Page
Pages have the same functionality as forms but are intended to run on the RoleTailored client. A page can be role tailored, to suite a users needs.

Zoom Funtion In Navision

In the Classic client, you use the Zoom feature on a form to view all fields for the current record that are in the table on which the form is based. For example, if you open a sales order form, click the Tools menu, and then click Zoom, then the Sales Header - Zoom window opens. The Sales Header - Zoom window shows all fields in the Sales Header table and the value of each field for the current record.
You can use the Zoom feature in the Classic client to help you troubleshoot and debug issues. For example, if you create a new form and need to troubleshoot the data that is displayed on the form, then you can use the Zoom feature to view all fields for the current record.

WITH Statements

Following is the Syntax For WITH statment.
WITH [Record] DO [Statement]
When you work with records, addressing is created as record name, dot (period),
and field name: [Record].[Field]
you work continuously with the same record, you can use WITH statements. When you use a WITH statement, you only have to specify the record name once.
Within the scope of [Statement], fields in [Record] can be addressed without having to specify the record name.
You can nest several WITH statements. In case of identical names, the inner WITH overrules the outer WITH-statements.
For Eg:
Consider a variable-'CustRec', Data Type -'Record', Subtype-'Customer'.
CustRec."No." := '10000';
CustRec.Name := 'Creative Solutions';
CustRec."Phone No." := '555-444-333';
CustRec.Address := '1352 Avenue';
CustRec.City := 'NewYork City';
MESSAGE('A variable has been created for this customer.');
The following example shows another way to create a record variable that you can commit later.
WITH CustomerRec DO
BEGIN
"No." := '10000';
Name := 'Creative Solutions';
"Phone No." := '555-444-333';
Address := '1352 Avenue';
City := 'NewYork City';
MESSAGE('A variable has been created for this customer.');
END;

Saturday, July 25, 2009

FOR,WHILE,REPEAT

C/AL Repetitive Statements
A repetitive statement is also known as a loop. The Different Loop statements are Given below.
1. FOR
2. WHILE
3. REPEAT

FOR
Repeats the inner statement until a counter variable equals the maximum or minimum value specified.
The Two Control Structures In FOR Statement are FOR TO and FOR DOWNTO.
The Syntax For The above control structures are given below.
FOR [Control Variable] := [Start Number] TO [End Number] DO
[Statement]
The data type of [Control Variable], [Start Number], and [End Number] must be Boolean, number, time, or date.
Use FOR statements when you want to execute code a specific number of times.
Use a control variable to control the number of times the code is executed. The control variable can be increased or decreased by one, depending on whether TO or DOWNTO is used.
When using a FOR TO loop, the [Statement] will not be executed if the [Start Number] is greater than the end value. Likewise, when using a FOR DOWNTO loop, the [Statement] will not be executed if the [Start Number] is less than the end value.
For Eg:
1. Consider a variable 'I' for Loop.
FOR I=1 To 5 DO
Statement 1;
2. The following example shows how to nest FOR statements.
FOR I := 1 TO 5 DO
FOR J := 1 TO 7 DO
A[I,J] := 23;

Thursday, July 23, 2009

IF THEN ELSE in Navision

IF THEN [ELSE]
A conditional statement is one type of control structure in C/AL.
Using Conditional Statements
By using a conditional statement, you can specify a condition and one or more commands that should be executed, according to whether the condition is evaluated as TRUE or FALSE. There are two types of conditional statements in C/AL:
1. IF THEN [ELSE], where there are two choices
2. CASE, where there are more than two choices.
IF THEN ELSE Statements
IF THEN ELSE statements have the following syntax.
IF (Condition) THEN (Statement1)
[
ELSE
(Statement2)
]
This means that if (Condition) is true, then (Statement1) is executed. If (Condition) is false, then (Statement2) is executed.
The square brackets around ELSE mean that this part of the statement is optional. The ELSE statement is used when different actions are executed, depending on the evaluation of (Condition).
You can build even more complex control structures by nesting IF THEN ELSE statements. The following example is a typical IF THEN ELSE statement.
IF (Condition1) THEN
IF (Condition2) THEN
Statement1;
ELSE
Statement2
Note: A semicolon preceding an ELSE is not allowed.
If 'Condition1' is false, then nothing is executed. If 'Condition1' and 'Condition2' are both true, then 'Statement1' is executed. If 'Condition1' is true and 'Condition2' is false, then 'Statement2' is executed.
Reading several nested IF THEN ELSE statements can be quite confusing but a general rule is that an ELSE belongs to the last IF that lacks an ELSE.
Example 1
The following example shows an IF statement without the optional ELSE part.
IF Amount (<) 1000 THEN Total := Total + Amount;
Example 2
The following example shows an IF statement with the optional ELSE part.
(1)...
(2) IF Amount (<1000) align="justify">(3) THEN BEGIN
(4) IF I > J THEN Max := I
(5) ELSE Max := J;
(6) Amount := Amount * Max;
(6) END
(7) ELSE
(8)...
A common error is to put an extraneous semicolon at the end of a line before an ELSE (line 4). As mentioned earlier, this is not valid according to the syntax of C/AL. The semicolon is used as a statement separator. (The end of line 4 is inside the inner IF statement.)
CASE Statements
CASE statements have the following syntax.
CASE (Expression) OF
(Value set 1) : (Statement 1);
(Value set 2) :(Statement 2);......
(Value set n) : (Statement n);
[ ELSE (Statement n+1) ]
CASE statements are also called multiple option statements and are typically used when you must choose between more than two different actions.
The function of the CASE statement is as follows:
1. The 'Expression' is evaluated, and the first matching value set executes the associated statement, if there is one.
2. If none of the value sets matches the value of the expression, and the optional ELSE part has been omitted, no action is taken. If the optional ELSE part is used, then the associated statement is executed.
The data type of the value sets must be the same as the data type of 'Expression' or at least be convertible to the same data type.
For Eg:
The following C/AL code prints various messages depending on the value of Number. If the value of Number does not match any of the entries in the CASE structure, the ELSE entry is used as the default.
CASE Number OF
1,2,9: MESSAGE('1, 2, or 9.');
10..100: MESSAGE('In the range from 10 to 100.');
ELSE MESSAGE('Neither 1, 2, 9, nor in the range from 10 to 100.');
END

BEGIN END Statements

A compound statement is one type of control structure in C/AL.
Using Compound Statements, In some cases, the C/AL syntax only allows you to use a single statement.
If however you have to execute more than one simple statement, the statements can be written as a compound statement by enclosing the statements between the keywords BEGIN and END.
BEGIN
Statement 1;
Statement 2;
.. ;
END

The individual statements are separated by a semicolon. In C/AL a semicolon is used to separate statements, and not, as in other programming languages, as a terminator symbol for a statement. Nevertheless, an extra semicolon before an END does not cause an error because it is interpreted by the compiler as an empty statement.
Blocks
The BEGIN-END structure is also called a block. Blocks can be very useful in connection with the other control structures in C/AL

Tuesday, July 21, 2009

C/AL Control Structures

All the C/AL programs that you create consist of one or more statements, which are executed sequentially in top-down order. However, you will often need to control the direct top-down flow of the execution. One or more statements may have to be repeated more than once, or you may have to make the execution of a certain statement conditional. To do this, you use control structures.

The control structures in C/AL are divided into the following main groups:

 1. Compound statements

 2. Conditional statements

 3. Repetitive statements

 4. WITH statements

System-Defined Variables

C/SIDE automatically declares and initializes a number of variables that you can use when you develop applications. The following details describes the system-defined variables.

Rec

When a record is modified, this variable specifies the current record, including the changes that are made.

xRec

When a record is modified, this variable specifies the original values of the record, before the changes.

CurrForm

This variable specifies the current form. You can access the controls of the form through this variable and set the dynamic properties of the form and its controls.

CurrReport

This variable specifies the current report.

RequestOptionsForm

This variable specifies the request options form for the current report.

CurrFieldNo

This variable specifies the field number of the current field in the current form. Retained for compatibility reasons.

Accounts in General Posting Setup

The description and use of Different GL Accounts in General Setup is given below.

Direct Cost Applied Account -

To post direct cost incurred in purchasing materials, capacity and subcontractor's services.

Overhead Applied Account -

To post indirect cost incurred in purchasing materials, capacity and subcontractor's services.

Inventory Account -

To post inventory value of purchased items and manufactured items.

Purchase Variance Account -

To post the difference between standard cost and direct cost of purchased inventory.

Inventory Account (Interim) -

To post expected inventory value. Use together with Inventory Accrual Account (Interim).

WIP Account - To post value of WIP Inventory.

Manufacturing Overhead Variance Account -

To post the difference between actual overhead cost incurred in manufacturing the item and the standard overhead cost for the item.

Capacity Overhead Variance Account -

To post the difference between the overhead cost of capacity consumed and the overhead (standard) cost of capacity setup in the routing for the manufactured item.

COGS Account (Interim) -

To post expected inventory decrease due to sales. Expected sales is posted when post ship without invoice. When Invoice is posted, cost in COGS (Interim) will be reversed out and posted to COGS account.

Inventory Adjustment Account -

To post inventory increase / decrease due to adjustement, revaluation and rounding

Saturday, July 18, 2009

Bulk Inserts

Bulk Inserts
Microsoft Dynamics NAV automatically buffers inserts in order to send them to SQL Server at one time. By using bulk inserts the number of server calls is reduced, thereby improving performance. Bulk inserts also improve scalability by delaying the actual insert until the last possible moment in the transaction. This reduces the amount of time that tables are locked; especially tables that contain SIFT indexes.
Application developers who want to write high performance code that utilizes this feature should understand the following bulk insert constraints.

Bulk Insert Constraints
If you want to write code that uses the bulk insert functionality, you must be aware of the following constraints. Records are sent to SQL Server when the following occurs:
You call COMMIT to commit the transaction.
You call MODIFY or DELETE on the table.
You call any FIND or CALC methods on the table.
Records are not buffered if any of the following conditions are met:
The application is using the return value from an INSERT call; for example,
"IF (GLEntry.INSERT) THEN".
The table that you are going to insert the records into contains any of the following:
BLOB fields
Variant fields
RecordID fields
Fields with the AutoIncrement property set to Yes
The following code example cannot use buffered inserts because it contains a FIND call on the GL/Entry table within the loop.
IF (JnlLine.FIND('-')) THEN BEGIN
GLEntry.LOCKTABLE;
REPEAT IF (GLEntry.FINDLAST) THEN
GLEntry.NEXT := GLEntry."Entry No." + 1ELSEGLEntry.NEXT := 1;// The FIND call will flush the buffered records.GLEntry."Entry No." := GLEntry.NEXT ;
GLEntry.INSERT;
UNTIL (JnlLine.FIND('>') = 0)END;
COMMIT;
If you rewrite the code, as shown in the following example, you can use buffered inserts.
IF (JnlLine.FIND('-')) THEN BEGIN
GLEntry.LOCKTABLE;
IF (GLEntry.FINDLAST) THEN
GLEntry.Next := GLEntry."Entry No." + 1ELSEGLEntry.Next := 1;
REPEAT GLEntry."Entry No.":= GLEntry.Next;
GLEntry.Next := GLEntry."Entry No." + 1;GLEntry.INSERT;
UNTIL (JnlLine.FIND('>') = 0)END;
COMMIT;// The inserts are performed here.

TESTFIELD & VALIDATE Functions

TESTFIELD Function
TESTFIELD tests whether a field contains a specific value. It has the following syntax.
Record.TESTFIELD(Field, [Value])
If the test fails, that is, if the field does not contain the specified value, an error message is displayed and a runtime error is triggered. This means that any changes that were made to the record are discarded. If the value that you test against is an empty string, the field must have a value other than blank or 0 (zero).
One of the main feature of this function is that, if you want to check any field where value is their or not, You can Use this function, So that without giving any data to that particular field, System won't allow the user to Post the document. For this you can simply write
TestField(Fieldname);
VALIDATE Function
VALIDATE calls the OnValidate trigger of a field. It has the following syntax.
Record.VALIDATE(Field [, NewValue])

CALCFIELDS, CALCSUMS Functions In Navision

CALCFIELDS updates FlowFields. FlowFields are automatically updated when they are the direct source expressions of controls, but they must be explicitly calculated when they are part of a more complicated expression.
CALCFIELDS has the following syntax.
[Ok :=] Record.CALCFIELDS(Field1, [Field2],...)
When you use FlowFields in C/AL functions, you must use the CALCFIELDS function to update them.
For Eg:
In the following example, the SETRANGE function sets a filter and then the CALCFIELDS function calculates the Balance and Balance Due fields by using the current filter and performing the calculations that are defined as the CalcFormula properties of the FlowFields.
Let the Variable Be 'Customer', Data Type be 'Record'.
Customer.GET(INDG-CUS-005); // Will Selct The Customer No: INDG-CUS-005
Customer.SETRANGE("Date Filter",0D,TODAY); // Will set the date Range for the Present Dt
Customer.CALCFIELDS(Balance,"Balance Due"); // Using, Calcfields system calcs the balance as per Dt.
MESSAGE('The Balance is %1 and your Balance Due is %2',Customer.Balance,Customer."Balance Due"); // Will Displays the balance in a Message Box, with Corresponding Value.
CALCSUMS Function
CALCSUMS calculates the sum of one or more fields that are SumIndexFields in the record.
CALCSUMS has the following syntax.
[Ok :=] Record.CALCSUMS (Field1, [Field2],...)
For CALCSUMS, a key that contains the SumIndexFields must be selected as the current key. Similar to CALCFIELDS, CALCSUMS uses the current filter settings when performing the calculation.
For Eg:
Let the Variable be 'CustLdgentry' & Datatype be 'Record'
CustLdgentry.SETCURRENTKEY("Customer No."); // will Set the Key Customer No.
CustLdgentry.SETRANGE("Customer No.",'50000','90000');// Will set Range of Customers No. From 50000-90000.
CustLdgentry.SETRANGE("Posting Date",0D,TODAY); // will Filter the posting date with Present date.
CustLdgentry.CALCSUMS("Sales (LCY)"); // Will Calculate total Sales Froam Sales(LCY) Field.
MESSAGE ('%1 calculated sales',custledgerentry."Sales (LCY)") // Total sales Amount in Local Currency Will be displayed in Message Box.

How to Check the User Name Who Locked the Table?.

This is because at same time two different users are trying to modify the values in same table. For the integerity and security of data, Navision won't allow mutiple users to modify the values in same table at a time. If You wan't to know,from which User ID, the sytem had locked it, Please follow the below steps.
Navision allow you to check which user is locking other users.
Step 1 #. Go to File-->Database-->Information.
Step 2 #. Select the Sessions tab.
Step 3#. Drill down to the current sessions.
Step 4#. Check on the Blocking user id column to find out who is locking other people.

Thursday, July 16, 2009

GETRANGEMIN, GETRANGEMAX Functions

GETRANGEMIN Function

GETRANGEMIN retrieves the minimum value of the filter range that is currently applied to a field.

GETRANGEMIN has the following syntax.
Record.GETRANGEMIN(Field);

A runtime error occurs if the filter that is currently applied is not a range. For example, you can set a filter as follows.
Customer.SETFILTER("No.",'100002000030000');

With this filter, the following code fails because the filter is not a range.

BottomValue := Customer.GETRANGEMIN("No.");

GETRANGEMAX Function

GETRANGEMAX retrieves the maximum value of the filter range that is currently applied to a field.

GETRANGEMAX has the following syntax.
Value := Record.GETRANGEMAX(Field)

SETCURRENTKEY, SETRANGE, SETFILTER Functions.

The following functions are used to filter records in a table: 

    #. SETCURRENTKEY

    #. SETRANGE

    #. SETFILTER

These functions are some of the most commonly used C/AL functions. They set limits on the value of one or more specified fields, so that only a subset of the records are displayed, modified, deleted, and so on.

SETCURRENTKEY Function


SETCURRENTKEY selects a key for a record and sets the sort order that is used for the table in question.

SETCURRENTKEY has the following syntax.
[Ok :=] Record.SETCURRENTKEY(Field1, [Field2],...)

When you use SETCURRENTKEY the following rules apply:

Inactive fields are ignored.

When searching for a key, the first occurrence of the specified field(s) is selected. This means the following:

If you specify only one field as a parameter when you call SETCURRENTKEY, the key that is actually selected may consist of more than one field.

If the field that you specify is the first component of several keys, the key that is selected may not be the key that you expect.

If no keys can be found that include the field(s) that you specify, the return value is FALSE. If you do not test the return value, a runtime error occurs. If you do test the return value, the program will continue to run even though no key was found. 

SETRANGE Function

SETRANGE sets a simple filter on a field.

SETRANGE has the following syntax.
Record.SETRANGE(Field [,From-Value] [,To-Value]);

In the following example, SETRANGE filters the Customer table by selecting only those records where the No. field has a value between 10000 and 90000.
Customer.SETRANGE("No.",'10000','90000');

When you use SETRANGE the following rules apply:

SETRANGE removes any filters that were set previously and replaces them with the From-Value and To-Value parameters that you specify.

If you use SETRANGE without setting the From-Value and To-Value parameters, the function removes any filters that are already set.

If you only set the From-Value, the To-Value is set to the same value as the From-Value.

SETFILTER Function


SETFILTER sets a filter in a more general way than SETRANGE.

SETFILTER has the following syntax.
Record.SETFILTER(Field, String [, Value], ...];

Field is the name of the field on which you want to set a filter. String is the filter expression. String may contain placeholders, such as %1 and %2, to indicate where to insert the Value parameter(s) in a filter expression.

The following example selects records where the value of No. is larger than 10000 and not equal to 20000.
Customer.SETFILTER("No.", '>10000 & <> 20000');

If the variables Value1 and Value2 have been assigned "10000" and "20000" respectively, then you can use the following statement to create the same filter.
Customer.SETFILTER("No.",'>%1&<>%2',Value1, Value2);

Wednesday, July 15, 2009

Code Differences in Locking procedure.

Locking Differences in the Code

A typical use of LOCKTABLE(TRUE,TRUE) in Classic Database Server is shown in the first of the following examples. The equivalent code for the SQL Server Option is shown in the second example. The code that works on both servers is shown in the third example. The RECORDLEVELLOCKING property is used to detect whether record level locking is being used. If this is the case, then you are using the SQL Server Option for Microsoft Dynamics NAV. This is currently the only server that supports record level locking.

Classic Database Server

Example 1

IF Rec.FIND('-') THEN

REPEAT
UNTIL Rec.NEXT = 0;
Rec.LOCKTABLE(TRUE,TRUE);
IF Rec.FIND('-') THEN
REPEAT
Rec.MODIFY;
UNTIL Rec.NEXT = 0;

SQL Server

Example 2

Rec.LOCKTABLE;
IF Rec.FIND('-') THEN
REPEAT
UNTIL Rec.NEXT = 0;
IF Rec.FIND('-') THEN
REPEAT
Rec.MODIFY;
UNTIL Rec.NEXT = 0;

Both Server Types

Example 3

IF Rec.RECORDLEVELLOCKING THEN

Rec.LOCKTABLE;
IF Rec.FIND('-') THEN
REPEAT
UNTIL Rec.NEXT = 0;
IF NOT Rec.RECORDLEVELLOCKING THEN
Rec.LOCKTABLE(TRUE,TRUE);
IF Rec.FIND('-') THEN
REPEAT
Rec.MODIFY;
UNTIL Rec.NEXT = 0;

Locking in Microsoft Dynamics NAV

This topic explains how locking is used in the two database options for Microsoft Dynamics NAV: 

1. Classic Database Server 

2. The SQL Server Option

Both Server Options

Locking

In the beginning of a transaction, the data that you read is not locked. This means that reading data does not conflict with transactions that modify the same data. If you want to ensure that you are reading the latest data from a table, you must lock the table before you read it.


Locking Single Records

Usually, you must not lock a record before you read it even though you may want to modify or delete it afterward. When you try to modify or delete the record, you get an error message if another transaction has modified or deleted the record. You receive this error message because C/SIDE checks the timestamp that it keeps on all the records in a database and detects that the timestamp on the copy you have read is different from the timestamp on the modified record in the database.

Locking Record Sets

Usually, you lock a table before reading a set of records in that table if you want to read these records again to modify or delete them. You must lock the table to ensure that another transaction does not modify these records.

You will not receive an error message if you do not lock the table even though the records have been modified as a result of other transactions being carried out while you were reading them.

Minimizing Deadlocks

To minimize the amount of deadlocks that occur, you must lock records and tables in the same order for all transactions. You can also try to locate areas where you lock more records and tables than you actually need, and then diminish the extent of these locks or remove them completely. This can prevent conflicts from occurring that involve these records and tables.

If this does not prevent deadlocks, you can, lock more records and tables to prevent transactions from running concurrently.

If you cannot prevent the occurrence of deadlocks by programming, you must run the deadlocking transactions separately.

Locking in Microsoft SQL Server


This topic explains how database locking works in Microsoft Dynamics NAV with Microsoft SQL Server.

Locking in SQL Server

When data is read without locking, you get the latest (possibly uncommitted) data from the database. If you call Rec.LOCKTABLE, nothing happens. However, when data is read from the table after LOCKTABLE has been called, the data is locked.

If you call INSERT, MODIFY, or DELETE, the specified record is locked immediately. This means that two transactions, which either insert, modify, or delete separate records in the same table do not conflict. Furthermore, locks are also placed when data is read from the table after the modifying function has been called.

SumIndexFields are maintained when INSERT, MODIFY, or DELETE is called. SQL Server places locks on the records to be updated in the underlying Indexed View. For example, if the application contains a SIFT index on a key consisting of only 'AccountNo' then only one user at the time will be able to modify records on a given AccountNo.

Even though SQL Server initially puts locks on single records, it can also choose to escalate a single record lock to a table lock. This will happen if the overall performance can be improved by not having to set locks on individual records. The improvement in performance must outweigh the loss in concurrency that this excessive locking causes.

If you specify what record to read, for example, by calling Rec.GET, that record is locked. This means that two transactions, which read specific, but separate records in a table does not cause conflicts.

If you browse a record set (read sequentially through a set of records), for example, by calling Rec.FIND('-') or Rec.NEXT, the record set (including the empty space) is locked as you browse through it. This means that two transactions, which just read separate sets of records in a table, will cause a conflict if there are no records between these two record sets. When locks are placed on a record set, other transactions cannot put locks on any record within the set.

Note that C/SIDE determines how many records to retrieve from the server when you ask for the first or the next record within a set. C/SIDE then handles subsequent reads with no additional effort, and fewer calls to the server give better performance. In addition set when you browse.

Microsoft Dynamics NAV with Microsoft SQL Server only supports the default values for the parameters of the LOCKTABLE function – LOCKTABLE(TRUE,FALSE).

Locking in Classic Database Server

Data that is not locked is read from the same snapshot (version) of the database. If you call a modifying function (for example, INSERT, MODIFY, or DELETE), on a table, the whole table is locked.

Locking Record Sets

Usually you lock a table before reading a set of records in that table if you want to read these records again and modify or delete them. With Classic Database Server, you can choose to lock the table with LOCKTABLE(TRUE,TRUE) after reading the records for the first time instead of locking with LOCKTABLE before reading the records for the first time.

When you try to modify or delete the records, you receive an error message if another transaction has modified the records.

You also receive an error message if another transaction has inserted a record into the record set. However, if another transaction has deleted a record from the record set, you will not notice this change. The purpose of locking with LOCKTABLE(TRUE,TRUE) after reading the records for the first time is to improve concurrency by postponing the table lock that Classic Database Server puts on the table.

LOCKTABLE Function

Ordinarily, when you are developing applications in C/SIDE, you do not need to take into consideration transactions and table locking. There are, however, some situations in which you must lock a table explicitly. To do this, use the LOCKTABLE function.

For example, in the beginning of a function, you inspect data in a table and then use this data to perform various checks and calculations. Finally, you want to insert a record based on the result of these calculations. To ensure that your calculations make sense, you must be certain that the values you retrieved at the beginning of the transaction are consistent with the data that is in the table now. You cannot allow other users to update the table while your function is performing its calculations.
LOCKTABLE Function

You can use the LOCKTABLE function to lock the table at the start of your function.

LOCKTABLE has the following syntax.
Record.LOCKTABLE([Wait] [, VersionCheck])

GET, FIND, and NEXT Functions

GET, FIND, and NEXT Functions

The following functions are used to search for records:

. GET

. FIND

. NEXT

These functions are some of the most commonly used C/AL functions. When you search for records, it is important to know the difference between GET and FIND and to know how to use FIND and NEXT in conjunction.

GET Function

GET retrieves one record based on values of the primary key fields.

GET has the following syntax.
[Ok :=] Record.GET([Value],...)

For example, if the No. field is the primary key of the Customer table and if you have created a Record variable called CustomerRec that has a Subtype of Customer, then you can use GET in the following way:
CustomerRec.GET('4711');

The result is that the record of customer 4711 is retrieved.

GET produces a runtime error if it fails and the return value is not checked by the code. In the preceding example, the actual code that you write should be similar to the following.
IF CustomerRec.GET('4711') THEN
.... // Do some processing.
ELSE
.... // Do some error processing.

GET searches for the records, regardless of the current filters, and it does not change any filters. GET always searches through all the records in a table.


FIND Function

FIND locates a record in a C/SIDE table based on the values stored in the keys.

FIND has the following syntax.
Ok := Record.FIND([Which])

The important differences between GET and FIND are the following:

FIND uses the current filters.

FIND can be instructed to look for records where the key value is equal to, greater than, or smaller than the search string.

FIND can find the first or the last record, depending on the sort order defined by the current key.

When you are developing applications in a relational database, there are often one-to-many relationships defined between tables. An example could be the relationship between an Item table, which registers items, and a Sales Line table, which registers the detailed lines from sales orders. One record in the Sales Line table can only be related to one item, but each item can be related to any number of sales line records. You would not want an item record to be deleted as long as there are still open sales orders that include the item. You can use FIND to check for open sales orders.

The OnDelete trigger of the Item table includes the following code that illustrates using FIND.
SalesOrderLine.SETCURRENTKEY(Type,"No.");
SalesOrderLine.SETRANGE(Type,SalesOrderLine.Type::Item);
SalesOrderLine.SETRANGE("No.","No.");
IF SalesOrderLine.FIND('-') THEN
ERROR(Text001,TABLECAPTION,"No.",SalesOrderLine."Document Type");


NEXT Function

NEXT is often used with FIND to step through the records of a table.

NEXT has the following syntax.
Steps := Record.NEXT([Steps])

In the following example, FIND is used to go to the first record of the table. NEXT is used to step through every record, until there are no more. When there are no more records, NEXT returns 0 (zero).
FIND('-');
REPEAT
// process record
UNTIL NEXT = 0;

Essential C/AL Functions

Although there are more than 100 functions in C/AL, there are several functions that you will use more often than the others.

1. GET, FIND, and NEXT Functions

2. SETCURRENTKEY, SETRANGE, SETFILTER, GETRANGEMIN, and GETRANGEMAX Functions


3. INSERT, MODIFY, MODIFYALL, DELETE and DELETEALL Functions

4. LOCKTABLE Function

5. CALCFIELDS, CALCSUMS,FIELDERROR, FIELDNAME, INIT, TESTFIELD, and VALIDATE Functions

6. Progress Windows, MESSAGE, ERROR and CONFIRM Functions

7. STRMENU Function

Guidelines for Placing C/AL Code

The following are simple guidelines for placing C/AL code:

In general, place the code as close as possible to the object on which it will operate. This implies that code which modifies records in the database should normally be placed in the triggers of the table fields that are involved.

In reports, always maintain a clear distinction between logical and visual processing and position your C/AL code accordingly. This implies that it is acceptable to have C/AL code in a section trigger if that code controls either the visual appearance of the controls or whether the section should be printed. Never place code that manipulates data in section triggers.

The principle of placing code near the object on which it operates can be overruled in some situations. One reason to overrule this principle is security. Normal users do not have direct access to tables that contain sensitive data, such as the General Ledger Entry table. If you place the code that operates on the general ledger in a codeunit, give the codeunit access to the table, and give the user permission to execute the codeunit, you will not compromise the security of the table and the user will be able to access the table.

There are reasons other than security for putting a posting function in a codeunit. A function that is placed in a codeunit can be called from many places in the application, including, perhaps, some that you did not anticipate when you first designed the application.

Reusing Code

The most important reason for placing C/AL code consistently, and as close to the objects that it manipulates, is that it lets you reuse code. Reusing code makes developing applications both faster and easier. More importantly, if you place your C/AL code as suggested, your applications will be less prone to errors. By centralizing the code, you will not inadvertently create inconsistencies by performing essentially the same calculation in many places


Where to Write C/AL Code

This section describes where to write C/AL code.  Almost every object in C/SIDE contains triggers where you can place your C/AL code. Triggers exist for the following objects:

The main Objects in Navision are

1. Tables

2. Table fields

3. Forms, including request forms

4. Form controls

5. Reports

6. Data items

7. Sections

8. Pages

You can initiate the execution of your C/AL code from the following:

   #. Command buttons

   #. Menu items

   #. Codeunits.

Friday, July 10, 2009

Brief About Dynamics NAV 2009

The long awaited Microsoft Dynamics NAV 2009 has been released If you have PartnerSource access, you can download Microsoft Dynamics NAV 2009 here.
This one is the most important release of Microsoft Dynamics NAV ever, as it brings a completely new architecture, a shiny new user interface, web-services enablement and much more.
The product is currently available in worldwide (W1) version and 13 localized releases in 9 languages.
Unlike any previous versions, this one is not focused on delivering new ERP functionality. From functional perspective it’s the same application as Microsoft Dynamics NAV 5.0 SP1, and no new application features have been introduced.
This has been a strategic move by Microsoft to help customers migrate to new platform easily without too many costs typically incurred by upgrade projects: customers upgrading from version 5.0 SP1 will merely have to upgrade the user interface. It is because data model and code equivalence of versions 5.0 SP1 and 2009, business logic and data model is something that won’t need an upgrade.
What’s new for the customers in the new release ?
Truly a lot, but I’ve picked these three as having deepest impact:
User Interface: The RoleTailored interface is a product of several years of Microsoft’s investment into research of user interaction. RoleTailored interface hides the complexity of underlying business logic from users, exposing only those functions pertaining to user’s role. The new user interface is much more intuitive and self-explanatory. Also, users will have one-click access to most-used functionality through Role Centers, organized dashboards which give direct insight into pending to-dos and tasks requiring user’s attention. Accessing one’s daily work doesn’t require browsing through labyrinths of screens and menus—typically, only what’s needed is shown in every screen, and there are vast personalization capabilities to make it all even simpler.
Web Services Enablement: It is now possible to expose any Microsoft Dynamics NAV functionality as a web service without any programming allow Microsoft Dynamics NAV to be seamlessly integrated into workflows extending far beyond system boundaries. Company’s internal processes, line-of-business applications, business-to-business and business-to-customer interactions can now be streamlined with significantly less investment into development and testing.
New Architecture: A completely new, 3-tiered architecture with new Service Tier introduced, a middle component which executes the business logic. This lays the foundation for more robust, scalable and concurrent solutions. New architecture allows for much more freedom in designing network infrastructure, and there will be less scenarios where Terminal Services were the only viable option. Also, higher scalability is now much easier to achieve, which means that Microsoft Dynamics NAV will be able to sustain growth of customer’s business much longer, preserving the investment.
Microsoft Dynamics NAV 2009 is going to be a hot topic of blogs, news sites, articles and analysts’ reports, as it makes the important step towards a single Microsoft Dynamics ERP platform,which sports the RoleTailored user interface, the new standard for all Microsoft Dynamics ERP products.

Thursday, July 9, 2009

Classic Architecture In NAV 2009

The Classic architecture is a term that describes the components carried forward from the 5.0 version of Microsoft Dynamics NAV.Microsoft has designed Dynamics NAV 2009 so that the Classic and RoleTailored architectures, and their respective components, can co-exist without conflict within a single organization.

Within the Classic architecture, the Classic client connects to either a Microsoft SQL Server database server or to a Classic database server (the proprietary NAV database server). In the RoleTailored architecture, SQL Server is the only database server.

The Classic client is the one Classic component that remains essential for all Microsoft Dynamics NAV 2009 installations, as a tool for development and administration tasks.

Classic Architecture Components

The components that make up the Classic architecture in Microsoft Dynamics NAV 2009 are:

. Classic Client 
. Classic Application Server 
. Classic Database Server

RoleTailored Architecture Components

RoleTailored Client

Microsoft Dynamics NAV 2009 provides an intuitive and customizable user interface called the RoleTailored client, which developers, partners, administrators, and super users can customize to support the job functions of different work roles in an organization.

For each role within an organization, the Microsoft Certified Partner or developer creates a customizable Role Center that displays key information required for relevant employees and makes their day-to-day tasks easier to complete. Users run the RoleTailored client to find the information and data entry points their jobs require.

For example, partners and developers can customize the sales order processor Role Center to display an interactive list of customers, daily activities, and sales information, and also give users easy access to their Microsoft Office Outlook e-mail, tasks, and calendar, all within the RoleTailored client.

The RoleTailored client is installed when you select either the Client Option or the Developer Environment Option in Microsoft Dynamics NAV Setup.

Microsoft Dynamics NAV Server

The Microsoft Dynamics NAV Server is a .NET-based Windows Service application that works exclusively with SQL Server databases. It uses the Windows Communication Framework as the communication protocol for RoleTailored clients and for Web services. It can execute multiple client requests in parallel and serve other clients by providing Web service access to authenticated clients.

A key difference between the two-tier architecture with the Classic client and three-tier architecture with the RoleTailored client and the Microsoft Dynamics NAV Server is that business logic runs on the Server instead of the client in the three-tier architecture. A simple example is the FILE.CREATE function. In previous versions of Microsoft Dynamics NAV, files are created on the client when code is run. With the RoleTailored architecture, the files are created on the service itself.

Microsoft Dynamics NAV Server provides an additional layer of security between the clients and the database. It leverages the authentication features of the Windows Communications Framework to provide another layer of user authentication and uses impersonation to ensure that business logic is executed in a process that has been instantiated by the user who submitted the request. This means that authorization and logging of user requests is still performed on a per-user basis. This ensures that all Windows authentication and Microsoft Dynamics NAV 2009 roles and permissions that have been granted to the user are correct. It also ensures that business logic–level auditing is still performed.

Microsoft Dynamics NAV Server is installed when you select either the Server Installation Option or the Developer Environment Installation Option in Microsoft Dynamics NAV Setup.

Database Components

The Database Components installation option in Setup installs the software that configures the Microsoft SQL Server database to work with Microsoft Dynamics NAV 2009.

If SQL Server is not present on the computer where you install the database components, Setup installs SQL Server Express 2005, which is an appropriate database option for prototyping and testing, but will likely prove inadequate for all but the smallest production environments.

Database components are installed when you select the Database Components Installation Option in Microsoft Dynamics NAV Setup.



About RoleTailored Architecture

     RoleTailored architecture components are new with Microsoft Dynamics NAV 2009. They work together to make the product more flexible, efficient, scalable, and secure, while also improving the user experience.

The Three Tiers of the RoleTailored Architecture

The RoleTailored architecture is a three-tiered architecture which contains the following levels:

Presentation level (RoleTailored client)

Business logic and communication level (Microsoft Dynamics NAV Server) 

Data level (SQL Server database)

The different tiers can be installed on different computers. You can have multiple instances of any of the components (though usually not on the same computer): multiple clients, multiple servers, and multiple database servers.

Here's a simple installation with two SQL Server database computers, each associated with a single Microsoft Dynamics NAV Server computer, each of which in turn supports two Microsoft Dynamics NAV RoleTailored clients:


         

RoleTailored Architecture Components

The components that make up the RoleTailored architecture in Microsoft Dynamics NAV 2009 are:

RoleTailored Client 

Microsoft Dynamics NAV Server 

Database Components and SQL Server

What's New in Microsoft Dynamics NAV 2009

This topic contains information about some of the new features and enhancements in Microsoft Dynamics NAV 2009.

1. Three-tier Architecture

With Microsoft Dynamics NAV 2009, the architecture has changed from a two- to three-tier architecture, enabling the new RoleTailored client and Web services.

2. Customizable, Role-Based User Interface

Microsoft Dynamics NAV 2009 provides a more intuitive and customizable user interface (UI) called the RoleTailored client, which you can modify to support the job functions of different work roles in your organization. For each role that you support, you can create a customizable Role Center that displays key information that is required by that role and makes day-to-day tasks easier to complete. Partners, administrators, and super users can customize the UI for specific roles, and individual users can also further personalize the UI to meet their specific needs.

3. Page Objects

Microsoft Dynamics NAV 2009 includes a new object called a page, which is used in the same way as a form. However, unlike forms, you have the flexibility to display pages in the RoleTailored client or to publish a page using a Web service.

You can also transform your existing form objects to page objects.

4. Improved Report Design and Functionality

Microsoft Dynamics NAV 2009 offers an improved reporting experience. You can now create interactive reports to which you can add charts, graphs, tables, and other data presentation elements that were not available in previous versions of Microsoft Dynamics NAV. You can also save your reports in .pdf or .xls file formats.

5. Business Connections with Web Services

Web services are a standard, widely used method for integrating applications and are supported in Microsoft Dynamics NAV 2009. By implementing Web services, you can access Microsoft Dynamics NAV data and business logic from outside the product in a standard, secure way. This enables you to connect Microsoft Dynamics NAV to other systems within an organization.

6. RoleTailored client control add-ins

RoleTailored client control add-ins extend the RoleTailored client with custom functionality. A control add(Available in NAV2009-SP1)-in is a visual element for displaying and modifying data on RoleTailored client pages.






Saturday, July 4, 2009

Navision Functionality That Can Connect Every Corner Of Business.

  • Financial Management
    GENERAL LEDGER
    • Basic General Ledger
    • Allocations
    • Budgets
    • Account Schedules
    • Account Schedules Bar Chart
    • Consolidation
    • Responsibility Centers
    • Basic Extensible Business Reporting
    Language (XBRL)
    • Change Log
    • Intercompany Postings
    • Reversal of Postings
    • Collapsible Chart of Accounts
    RECEIVABLES
    • Basic Receivables
    • Sales Invoicing
    • Sales Order Management
    • Sales Invoice Discounts
    • Alternative Ship-to’s
    • Order Promising
    • Shipping Agents
    • Sales Return Order Management
    • Calendars
    • Sales Line Discounting
    • Sales Line Pricing
    • Campaign Pricing
    • Sales Tax
    • VAT
    • Unapply
    • Partial Payment
    FIXED ASSETS
    • Basic Fixed Assets
    • Insurance
    • Maintenance
    • Fixed Assets Allocations
    • Reclassification
    PAYABLES
    • Basic Payables
    • Purchase Invoicing
    • Purchase Order Management
    • Purchase Invoice Discounts
    • Requisition Management
    • Alternative Order Addresses
    • Purchase Return Order Management
    • Purchase Line Discounting
    • Purchase Line Pricing
    • Drop Shipments
    • Unapply
    • Partial Payment
    • Check Writing
    • Bank Reconciliation
    Analytics
    • Report Generator
    • Account Schedules
    • Analysis by Dimensions
    • Business Analytics for Microsoft Navision
  • Distribution
    INVENTORY MANAGEMENT
    • Basic Inventory
    • Multiple Locations
    • Stockkeeping Units
    • Alternative Vendors
    • Bills of Materials
    • Location Transfers
    • Item Substitutions
    • Item Cross References
    • Nonstock Items
    • Item tracking
    • Item Charges
    • Cycle Counting
    • Bin
    • Put Away
    • Warehouse Receipt
    • Pick
    • Warehouse Shipment
    • Standard Cost Worksheet
    • Business Notifications
    WAREHOUSE MANAGEMENT
    • Warehouse Management Systems
    • Internal Picks and Put Aways
    • Automated Data Capture Systems
    (ADCS)
    • Bin Set-up
    • Returns Management
    • Shipment and Delivery
    Manufacturing
    BASIC MANUFACTURING
    • Production Orders
    • Production Bills of Materials
    AGILE MANUFACTURING
    • Version Management
    • Agile Manufacturing
    SUPPLY PLANNING
    • Basic Supply Planning
    • Demand Forecasting
    CAPACITY PLANNING
    • Basic Capacity Planning
    • Machine Centers
    • Finite Loading
    • Manufacturing Costing
    Customer Relationship Management
    SALES AND MARKETING
    • Contact Management
    • Contact Classification
    • Campaign Management
    • Opportunity Management
    • Task Management
    • Document Management and Interaction
    Log
    • Contact Search
    • E-Mail Logging for Microsoft Exchange
    • Microsoft Outlook Client Integration
    SERVICE MANAGEMENT
    • Service Item Management
    • Service Price Management
    • Service Order Management
    • Service Contract Management
    • Planning and Dispatching
    • Job Scheduling• Electronic Payments (ACH)
  • Human Resource Management
    • Payroll
    • Direct Deposit
    • Communications
  • CUSTOMIZATION TOOLS
    • C/SIDE
    • Navision Developer’s Toolkit
    • Client Monitor
    • Code Coverage
    • Navision Debugger
    • Navision Application Server
    • C/ODBC
    • C/FRONT
  • ADDITIONAL APPLICATION-WIDE GRANULES
    • Multiple Currencies
    • Multiple Document Languages
    • Multiple Languages (Each)
    • Extended Text
    • Reason Codes
    • Basic Dimensions
    • Advanced Dimensions
    • Reports
    • Intrastat
    • Payroll
    • Direct Deposit
    • Communications

5 Ways Microsoft Dynamics NAV Helps You Focus on Your Business

  • Microsoft Dynamics NAV connects your entire business.
    You can use Microsoft Dynamics NAV to replace as much or as little of your existing system as necessary. You choose from application areas for financial management, manufacturing, distribution, customer relationship management, and e-business.
  • It lets you run your business the way you want.
    A local Microsoft Certified Partner tailors the software to meet your exact needs. The partner works closely with you using our proven methodology and tools. Together, you map out your business processes and identify your competitive strengths.
  • You get quick answers about your business.
    Every time a transaction is posted—anywhere within the system—all customer, vendor, account, and item totals are given in real time. You can zero in on details by filtering information (for example, by date, account, or item number) and always rely on the absolute accuracy of the information.
  • You get more out of customer relationships.
    All your business information—customer, product, inventory, sales—is integrated, so you can make better decisions. You know which accounts need your immediate attention, and which can wait. And you can target your sales and marketing campaigns based on specific criteria, such as sales, contact profiles, and previous interactions.
  • It helps you master change.
    Information is transparent, whether you use Microsoft Dynamics NAV to manage the back office, the warehouse, or the shop floor. If a customer calls to change his order in the last minute, for example, you can check the production status, and adjust plans immediately from the sales order.

Microsoft Dynamics NAV




A comprehensive, easy-to-use ERP software system, Microsoft Dynamics-Navision ERP enables mid-size organizations to streamline business processes for accelerated growth. You can tailor Microsoft Dynamics-Navision to your business processes—manufacturing, distribution, financial management, sales and marketing, human resources, and others—and use it to accomplish your goals with optimal efficiency.
The Official Website For Dynamics- Nav is www.microsoft.com/dynamics/nav/default.mspx