1.
Difference b/w this.queryBuildDataSource(); and this.queryrun().querybuilddatasouce;?
·
It depends on what "this"
is. Supposing that it's a form data source, the latter data source includes
changes done by a user, e.g. additional ranges.
2.
Difference b/w temp table and a Container?
Microsoft Dynamics AX supports a special data type called a
container. This data type can be used just as you would use a temporary table.
Data in containers are stored and retrieved sequentially, but a
temporary table enables you to define indexes to speed up data retrieval.
Containers provide slower data access if you are working with many records.
However, if you are working with only a few records, use a container.
Another important difference between temporary tables and containers
is how they are used in method calls. When you pass a temporary table into a
method call, it is passed by reference. Containers are passed by value. When a
variable is passed by reference, only a pointer to the object is passed into
the method. When a variable is passed by value, a new copy of the variable is
passed into the method. If the computer has a limited amount of memory, it
might start swapping memory to disk, slowing down application execution. When
you pass a variable into a method, a temporary table may provide better
performance than a container.
3.
Difference b/w active/passive/delayed join?
Form data source link types
Form
data source link type is a property of the form data source. We can add more
than one tables as a data source to the form. Those data sources should has the
table level relation, So, then the developer no need to work on the coding part
to find the relation records. For example, if we create the order form, that
order form has orders and order details tables as form datasources. We can add
both tables as a data sources to the form.
The
parent table and child table should has the table relation. So, once we add
these tables in the form as data sources. We can select the child table data
source and mention the parent table name in the join source property of the
child table form data source property.
Example:
Here, I have created
two tables Hari_Order and Hari_OrderDetails. Hari_OrderDetails has the foreign
key of Hari_Order table Key is OrderNo.
Hari_Order
table
Order No
|
Customer Name
|
Ord 2
|
Ram
|
Ord 1
|
Hari
|
Ord 3
|
Vithyaa
|
Ord 4
|
Uma
|
Hari_OrderDetails
Order No
|
Product Name
|
Product Description
|
Ord 1
|
Prod 1
|
Product One
|
Ord 1
|
Prod 2
|
Product Two
|
Ord 1
|
Prod 3
|
Product Three
|
Ord 2
|
Prod 1
|
Product One
|
Ord 2
|
Prod 2
|
Product Two
|
Ord 3
|
Prod 1
|
Product One
|
Set the join source
and set the link type
Table
relation
Use
join source and link type
Active
Active link type
update the child data sources without any delay when you select the parent
table record. When you deal with more records it will be affect application
performance.
Delay
Delay form data source
link type is also same as active method the different is delay method won't
update immediately when you select the parent record. It will update the child data
source when you select the parent table, Ax use pause statement before update
the child data source. For example, if we are dealing with lot of records so,
when the user click or scroll the order, order details will update without any
delay if we use active method.
So, We can use delay
method because of performance improvement.
Passive
Passive form data
source link type won't update the child data source automatically. For example
if we select the parent table order then order details child data source won't
update. If we need to update the child data source we need to call the child
data source execute query method by program (code).
The order details grid
is empty. If we need populate the child data source (order details) then we
need to call the Hari_OrderDetails_ds.executeQuery() method in the parent table
Hari_Order form data source active method. We can add separate button "Populate
order details" and call the code Hari_OrderDetails_ds.executeQuery(). So,
if the user need to see the order details then the user update by click the
"Populate order details" button.
Inner
join
Inner join form data
source link type displays the rows that match with parent table and child
table. For example if the order doesn't has any order details then the order
will not be display.
Here, Order 4 does not
has the order details records, so it is not coming in the order grid.
Outer
join
Outer join form data
source link type will return all parent records and matched child records. It
will return all rows in the parent table. Here, Order 4 doesn't has the child
records (order details) but it is populating in the order grid. It is the
difference between inner join and outer join.
Here, Order 4 is
coming even order 4 does not has the order details.
Exist
join
Exist join form data
source link type return matched rows of the parent table. It behaves like inner
join but the different is once parent row matched with child records then stop
the process and update in the grid, Ax won't consider how many records in child
table for the parent row.
Here, Order 4 is not
coming because Order 4 does not has the order details.
Not
exist join
Not exist join form
data source link type is totally opposite method to exist join. It will return
the not matched parent records with child records.
Here, Order 4 is
coming because order 4 does not has the order details.
Each form data source
link type has different behavior. Active, Delay and Passive are one category
and Inner join, Outer join, Exist join, Not exist join are another category.
So, please understand the behavior and choose the link type based on your
requirement.
About
Joins
We use joins to link tables so that they can return values
together. By default, inner joins are created.
The following table below describes the types of joins
available:
Inner: Combine records into one table only when there
are matching values in a common field.
Outer: Combine records into one table
even if there are no matching values in the common field.
Exists: Combine records from one table
whenever a value exists in a common field in another table.
Not Exists: Combine records from one table
whenever a value in a common field in another table does not exist.
4.
How to create a primary key for a table?
1) Create the Table and add required fields to the table as you
all knows.
2) Create an Index by dragging the required field to the Index.
3) Set the following Index properties:
a)
AllowDuplicates to "NO".
b) Alternate key
to "YES".
4) Set the PrimaryIndex
property of the table to newly created index after creating the Index.
5.
what precautions you need for overriding fetch()
method for a report?
You can override the fetch method to filter the data that is displayed
in a report. This override does not reduce the number of records that are
returned by the query of the report. Instead it prevents some records from
being sent to the final report. Each record is examined by the branching logic
you add to the fetch method. Branching determines which records
to give to the send method. Those records appear in the final
report.
Note : Do not
call super() when you override the fetch method in a report.
By default, each record that is returned by the query appears
in the report. To reduce the number of records returned, add range restrictions
to the query. Report ranges are more efficient than overriding the fetch method; however, report ranges are less
expressive. For information about adding ranges to queries
6.
Difference between OCC and PCC?
OCC: - Optimistic Concurrency Control
Optimistic Concurrency Control (OCC)
helps increase database performance, Optimistic Concurrency only locks records
from the time when the actual update is performed
OCC Enabled: Yes
PCC: - Pessimistic Concurrency Control
Pessimistic
Concurrency Control locks records as soon as they are fetched from the database
for an update. Pessimistic concurrency was the only option available in
Microsoft Axapta 3.0 (now a part of Microsoft Dynamics).
7.
How many types of MAP there in Dynamics
AX?
X++ Maps and AOT Maps
X++ Maps:
it can be used as a temp data store for the given scope of a process. This
takes us less over head, and is much quicker than a TempTable.
Map class allows you to associate one value (the key) with
another value. Both the key and value can be any valid X++ type, including
objects. The types of the key and the value are specified in the declaration of
the map. The way in which maps are implemented means that access to the values
is very fast.
AOT Maps: A map
can unify the access to similar columns and methods that are present in
multiple tables. You associate a map field with a field in one or more tables.
This enables you to use the same field name to access fields with different
names in different tables. Methods on maps enable you to create or modify methods
that act on the table fields that the map references.
8.
What is cache lookup what is it used for?
Caching, one of the concepts generally ignored by the
developer. This mainly seems to be due to the underlying complexity involved in
analyzing it.
But in reality, it’s not that complicated. Let’s break it
Caching in simple terms, is a temporary storage area where
frequently accessed data can be stored for rapid access. Once the data is
stored in the cache, it can be used in the future by accessing the cached copy
rather than re-fetching or recomputing the original data. (Definition Source:
Wikipedia)
In Ax, we have 2 caches.
1. Server Cache
2. Client Cache
Client Cache is used only when a select is executed on
client-tier. If a record is not in client cache, it looks in server Cache, and
if not, it costs a database fetch. Maximum #records stored in client cache are
100 per table, per company, whereas, in ServerCache, this limit is 2000.
To know whether a record is fetched from client cache, server
cache or database, use wasCached() of the TableBuffer used in Select.
select * from salesTable where salesTable.salesId == 'AR_2009';
info(strfmt("%1",salesTable.wasCached()));
We have 2 types of caching mechanisms in Ax:
Set Based Cache – Caches a set of records.
Single-record Cache – Caches records based on Select
Statement used.
Set Based Caching:
As the name implies, with set based caching, we can cache a set
of records.
A set of records fetched by a Select Statement can be cached by
using an instance of RecordViewCache, provided the Select is with NoFetch
option. (Temporary tables & Selects with Joins cannot be cached this way)
After instantiating, the RecordViewCache is used by Select that
matches at least the where clause that the RecordViewCache was instantiated
with
In a TTSBlock, if the select is used with forUpdate, it will
lock all the records in RecordViewCache, and
the next select forUpdate statements will use locked records from cache.
(To check these records, use the sql select (with nolock) *
from <<TableName>> where ……… )
If select is used without any where clause, entire table will
be cached. A record view cache will be destroyed, as soon it goes out of scope.
But there are better ways to cache an entire Table. Lets see
that:
Entire Table Cache:
Once a record fetched, the entire table will get cached, for a
period of AOS lifetime, when the cacheLookup Property of a Table is set to
EntireTable. This cached full set of
records , will reside in the Server Cache.
Once fetched, cache will have set of table records, per company.
Note: In my
experiments I found that, when a record of a table(cached EntireTable) is
fetched, remaining records are not fetched…
Single-Record Caching
Instead of caching a set of records, we can cache individual
records that were fetched succesfully based on a ‘where’ clause of ‘select ‘,
using Single record caching. When a table is set to Single Record Caching, all
records fetched from database are placed in cache, provided it is they are
fetched with unique index key. Subsequent fetches are made from cache.
A table is set to Single Record Cache by setting cache-lookup
property to one of the following:
NotInTTS
Found
NotFound
However, there is a significant difference among these.
Depending on usage, corresponding type must be used.
NotInTTS:
When a table is set to NotInTTS, a fetch operation inside a
transaction will fetch the record from database. Subsequent fetches are made
from cache. This is an useful mechanism to avoid reading/updating outdated data
inside a transaction.
Fetch made outside a transaction: Client cache -> Server Cache ->
Database -> Server Cache -> Client Cache
Fetch made inside a transaction: Client cache -> Server
Cache -> Database -> Server Cache -> Client Cache
Found:
When a table is set to Found, a fetch for update inside a
transaction will fetch record from database. Subsequent fetches are made from
cache. This is an useful mechanism to
avoid updating outdated data inside a transaction.
Fetch made outside a transaction: Client cache -> Server
Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction: Client cache -> Server
Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction for update : Client cache ->
Server Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction that doesn’t exist: Client
cache -> Server Cache -> Database -> Server Cache -> Client Cache
NotFound:
When a table is set to NotFound, it functions like Found,
except that it also caches non succesful fetches. Which means, when a record
that does not exist is fetched from database, the condition used for fetching
is cached. Subsequent non succesful fetches, will not search full database.
Instead, just concludes from cache that record does not exist.
Fetch made outside a transaction: Client cache -> Server
Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction: Client cache -> Server
Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction for update : Client cache ->
Server Cache -> Database -> Server Cache -> Client Cache
Fetch made inside a transaction that doesn’t exist: Client
cache -> Server Cache -> Database -> Server Cache -> Client Cache
9.
Difference between table, views and Map?
Tables, views, and maps are elements that X++ SQL statements
can reference to read and write business data. These elements are specified in
the Application Object Tree (AOT) under AOT > Data Dictionary. The following
table describes these elements.
Tables:
Tables store business data. Each table in the AOT has a
corresponding table in the underlying Microsoft SQL Server database.
In Microsoft Dynamics AX, tables have advanced features beyond
what tables might have in the underlying database. The advanced features
include the following:
·
Method
members – A table can have methods, just as a class in X++ or C# can have
methods.
·
Table
inheritance – A table can extend, or be derived from another table. That
same table can be the base table for several derived tables.
·
Valid
time state – A table can be configured to track data relationships for
specific date-time spans.
Tables are specified at AOT > Data
Dictionary > Tables.
Views:
A view is an X++ SQL select statement that is given a name that is
reusable in other X++ SQL statements. The select statement of the view can reference one
table, or it can join tables. Also, a view can reference other views, or a mix
of views and tables. A view can also reference maps.
Developers are encouraged to consider using an AOT
query element as the source of data for their
view.
Views are specified at AOT > Data Dictionary > Views.
Maps:
A map can unify the access to similar columns and methods that
are present in multiple tables. You associate a map field with a field in one
or more tables. This enables you to use the same field name to access fields
with different names in different tables. Methods on maps enable you to create
or modify methods that act on the table fields that the map references.
Maps are specified at AOT > Data Dictionary > Maps.
10.
Why we use dialog? And how
to accomplished it?
A dialog in Microsoft Dynamics AX is a simple form with a
standardized layout, created by using the Dialog system class.
Dialogs should allow users to enter some simple values. Do not
create complex dialogs—create forms instead.
Dialogs are non-modal. The dialog should not open a secondary
window that requires user interaction. All user interaction should be carried
out within the dialog.
1. Open the AOT, and create a new class with the following
code, its important ro extend RunBase because the RunBase framework uses the
Dialog framework to prompt a user for data input. It uses the SysLastValue
framework to persist usage data and the Operation Progress framework to show
operation progress:
class
CustCreateDialog extends RunBase
{
DialogField fieldAccount;
DialogFIeld fieldName;
CustTable
custTable;
CustAccount custAccount;
}
2. Override the method Dialog, this method will be used to give
“form” to our Dialog:
protected
Object Dialog()
{
Dialog dialog;
;
dialog = super();
//
Set a title for dialog
dialog.caption( 'Simple Dialog');
// Add a new field to Dialog
fieldAccount = dialog.addField(
extendedTypeStr(CustVendAC), 'Customer account' );
return dialog;
}
3. Override the method getFromDialog, the code below will be
used to retrieve the Dialog field values:
public
boolean getFromDialog()
{
// Retrieve values from Dialog
custAccount = fieldAccount.value();
return super();
}
4. Override the method run, use it to process whatever you want
to. On my example I will use it to show the customer account information on
infolog.
public
void run()
{
// Set Dialog field value to find CustTable
custTable = CustTable::find(custAccount);
if (custTable)
{
// Shows retrieved information
info( strFmt('%1 -- %2' ,
custTable.AccountNum, custTable.name()));
}
else
{
error( 'Customer Account not found!');
}
}
5. Create a new main method to execute your class.
public
static void main(Args _args)
{
CustCreateDialog custCreate = new
CustCreateDialog();
// Prompt the dialog, if user clicks in OK
it returns true
if (custCreate.prompt())
{
custCreate.run();
}
}
6. Execute your class, check results.
11.
What are the different type of index?
Indexes in databases are used to locate records and they are
stored separately in the database. They contain a key that can be quickly
located in the index, and this key will have a reference to a record.
For example, the let’s think on the SalesIdx index
in the Sales Table. This table field index contains the SalesId of a Sales
Order. Now, because the Sales order is unique and sequenced, an index will be
used to quickly lookup the sales orders records through the reference.
Type
of Indexes
Unique
A unique index is created based on a column; Microsoft Dynamics
AX assures that no duplicate key values can occur in that same column. Also,
when updating a column that contains a unique index will cause an error.
Non-Unique
Non-unique indexes are created for performance reasons. In
other words, they give a fast way of retrieving data. For example, (and here we
can think on the example above about the SalesIdx) instead of doing a
full-table search of all the records in a table, and non-unique index will help
us narrow down this search to a reference.
In general, indexes use system space and must be updated
every time system data is created, edited, or deleted. I have seen indexes
slowing down the updating process. However in most cases the overall
performance improvement when selecting records far outweighs the performance
loss when updating.
Microsoft recommends that when creating an index to give it a
name that reflects the names of the fields on a table plus the suffix Idx.
(i.e. SalesIdx)
Creating
Indexes
Creating indexes is not very difficult at all. You just want to
make sure that the fields you want to create the index on exist in the table (I
guess this is obvious, but you’ll be surprise with some of the question I have
been asked over the years). Anyway, the indexes can be unique or non-unique,
and are based on a single column or multiple columns that exist within the
table.
Locate a table in the
AOT (This has to be a table in your Dev environment or some virtual machine AX)
Right-click the
Indexes node in the table and select New Index. A new index Index1 is
created.
Rename the index
to the field name of the table/field you have chosen
Drag the field you
have chosen to the index created in the step above node.
In the properties
sheet for the created index node, set the property AllowDuplicatesto No.
Just to make it more visually clear, please take a look at the
following picture:
12.
Difference
b/w cascade + restricted and restricted delete
actions?
Delete actions on a table are used for two purposes
·
Restrict the deletion of a record based on
related records in another table
·
Cascade the deletion of a record to related
tables to ensure data-consistency
The Restrict component of a
delete action occurs during the call to .validateDelete() on the table. If a
deletion is performed from a form, then this method is called automatically.
From code however, the delete restriction will have no effect unless the
programmer explicitly calls .validateDelete() and checks the return value
before deciding whether to go ahead with the deletion. The Cascade component of
a delete action occurs during the call to .delete() on the table. There exists
also a property skipDeleteActions(boolean) which changes the behaviour of the
validateDelete() and of the delete()-Methods.
Delete actions are added in the AOT, by right-clicking on the
DeleteActions node of a Table AOT element. Select New DeleteAction and then select the table on which this delete
action will be based.
There are four different types of delete actions
1. None
2. Cascade
3. Restricted
4. Cascade+Restricted
None:
A None deletion action will delete selected row in the table
but nothing occurs to the table that relate to this table.
Cascade:
A restricting delete action will raise an error message if the
user tries to delete a record, where records exist in the related table where
the foreign key is equivalent to the primary key of the current table.
This error will only appear if the deletion is performed
through the user interface. A deletion from X++ code will be allowed to proceed
and will not be cascaded to the related table. In this case
the programmer should call .validateDelete() themselves prior to the call to
.delete()
Cascade+Restricted
The delete action performs a restricted, if the record of the
table will be deleted directly and performs a cascade, if the record of the
table will be deleted through a cascade delete action of another table. e.g.:
tableA (Customer) (a cascade deleteaction to tableB) tableB (SalesOrder) (a
cascade+restricted deleteaction to tableC) tableC (SalesLine)
When a record of tableB will be deleted, the restricted part of
the deleteaction will be performed. The record of tableB can only be deleted,
if no record in tableC exist for the record in tableB. (The SalesOrder can only
be deleted, if no SalesLine exist for the SalesOrder).
A record in tableA will be deleted, so the cascade deleteaction
to tableB will be performed. In this case, the cascade part of the deleteaction
to tableC will be performed. (When a Customer will be deleted, the SalesOrders
and SalesLines will also be deleted)
13.
Explain sales/purchase order processes in AX ?
Sale Orderà Confirmationà Picking
and Packing SlipÃ
Invoicing
Purchase Orderà Confirmationà Packing
Slipà Product
Recieptà Invoicing
14.
Difference between edit and display method?
Display indicates that the method's return value is to be
displayed on a form or a report.
The value cannot be altered in the form or report
Edit indicates that the method's return type is to be used to
provide information for a field that is used in in a form. The value in the field can be
edited.
15.
Difference between
perspectives and table collection
Perspectives can organize information for a report model in the
Application Object Tree (AOT).
A perspective is a collection of tables. You use a report model
to create reports.
Table collection is a collection of table, which sharing across
all the virtual companies.
16.
What is the difference between Auto Design Spec
& Generated Design
Auto Design:
An auto design is a report design that has a layout that is automatically
generated based on the data for the report. You can use auto designs for most
common reports. Reusability is available.
This uses Report template and Section template. Header, Section
Group and Footer is not available.
Generate Design or
Precision design: You can create a precision design for a report that
requires a very precise layout. It doesn’t use Section template and Report
template. Reusability is not available.
17.
Why do we provide Configuration key &
Security Key?
Configuration key:
Configuration keys allow administrators to enable or disable features in the
application for all users. Disabling features helps to minimize the attack
surface against potential attacks.
Configuration keys are applied to:
·
Tables
·
Fields
·
Indexes
·
Views
·
Menus
·
Menu items
·
Form controls,
·
Report controls
·
Extended data types
·
Enumerations
Security key:
Security keys allow administrators to set security on a user group level.
Minimizing access on a user group level helps to reduce the attack surface
against potential attacks.
The main reasons to apply user-level security are to:
Allow users to do only their designated tasks.
Protect sensitive data in the database.
Prevent users from inadvertently breaking an application by
changing code or objects on which the application depends.
You need to apply a security key to:
·
Tables
·
Views
·
Menus
·
Menu items
·
Form controls
·
Report controls
18.
Menu Items type?
Disply : For Forms.
Output : For Reports.
Action : For Classes.
19.
Difference between pass by reference and pass by
value?
Pass By Reference:
In Pass by reference address of
the variable is passed to a function. Whatever changes made to the formal
parameter will affect to the actual parameters
·
Same memory
location is used for both variables.(Formal and Actual)-
·
it is useful when
you required to return more than 1 values
Pass By Value:
·
In this method
value of the variable is passed. Changes made to formal will not affect the
actual parameters.
·
Different memory
locations will be created for both variables.
·
Here there will
be temporary variable created in the function stack which does not affect the
original variable.
In case of pass by value, the
change in the sub-function will not cause any change in the main function
whereas in pass by reference the change in the sub-function will change the
value in the main function.
Pass by value sends a COPY of
the data stored in the variable you specify, pass by reference sends a direct
link to the variable itself. So if you pass a variable by reference and then
change the variable inside the block you passed it into, the original variable
will be changed. If you simply pass by value, the original variable will not be
able to be changed by the block you passed it into but you will get a copy of
whatever it contained at the time of the call.
20.
What are the classes, Tables, Forms and Methods
used to post the sales orders?
SalesTableType and SaleslineType classes
will get called while creating
the SalesOrders.
SalesFormLetter_Confirm
SalesFormLetter_Invoice
SalesFormLetter_PackingSlip
SalesFormLetter_PickingLlst
classes will be used to post the sales order at various document status
(packing, invoice etc).
Tables:
SalesTable contains all SalesOrder headers regardless whether
they have been posted or not.
The SalesParmTable and SalesParmLine contains
detailed information regarding posting sales headers and Lines.
CustConfirmJour and CustConfirmTrans tables contains all
Sales Confirmation headers and Lines
posted in Dynamic Ax originating from Sales Orders and Lines.
CustPackingSlipJour and CustPackingSlipTrans tables contains all sales PackingSlip headers and Lines
posted in Dynamic Ax originating from Sales Orders and Lines.
CustInvoiceJour and CustInvoiceTrans tables
contains all
sales all Sales Invoice headers and Lines posted in Dynamic Ax
originating from Sales Orders and Lines.
21.
What are the classes, Tables, Forms and Methods
used to post the Purchase orders?
PurchTableType and PurchTableLine classes will get
called while creating the PurchaseOrders.
PurchFormLetter_PurchOrder
PurchFormLetter_ApproveJournal
PurchFormLetter_Invoice
PurchFormLetter_PackingSlip
PurchFormLetter_ReceiptsList
classes will be used to post the PurchaseOrder
at various document status (packing, invoice etc).
Tables:
PurchTable contains all purchase
order headers regardless whether they have been posted or not.
PurchParmTable and PurchParmLine contains detailed
information regarding posting Purchase
headers and Lines.
VendPackingSlipJour and VendPackingSlipTrans tables contains
posted packingslip headers and lines.
VendInvoiceJour and VendInvoiceTrans tables contains all invoiced purchase order
headers and Lines.
VendReceiptsJour and VendReceiptsTrans tables contains
posted receipt header and lines.
VendPurchOrderJour and VendPurchOrderTrans tables contains
Purchase requisition headers and lines.
22.
What is the difference between RunBase and
RunBaseBatch?
RunBase: To
create a job or an Action class - a program that carries out processes, such as
accepting parameters from the user and then updating records in the database -
you use the RunBase framework.
The framework is implemented by the RunBase application class
and supplies many features, which include the following:
·
Query
·
Dialog, with persistence of the last values
entered by the user
·
Validate
The RunBase class is a framework for classes that need a dialog
for user interaction and that need the dialog values to be saved per user.
RunBaseBatch: You can design your own batch job by
extending the RunBaseBatch class. You can also write code to schedule the batch
to run. The batch runs on the Application Object Server (AOS)
23.
What’s new in AX 2012?
·
Valid time state tables that contain date
effective data.
·
The UnitOfWork class to simplify database transaction
management.
·
Inheritance among tables, similar to class
inheritance.
·
Full text index support to quickly query words
that are embedded in the middle of a string field of a table.
·
TempDb tables are a second type of
temporary table, in addition to the legacy InMemory temporary
table. TempDb tables can be joined to regular tables in a
query.
·
Computed columns in a view.
·
Filters on queries that perform an outer join.
·
Disabled tables can be retained in the
underlying database for access by external applications.
24.
Difference between AX 2012 and AX 2009?
25.
Pack and Unpack method?
Use the pack-unpack pattern to save and/or store the state of
an object, and then later reinstantiate the same object.
Pack():create
a pack method to read the state of the object and return it in a container
suitable for saving or transporting between tiers. Reading the state of the
object implies collecting the value of all its members. If the members are
tables (records, cursors, temporary tables) or classes, it must also be
possible to read their state.
Returns the state of the object as a container.
Unpack():create
an unpack method that takes the packed state and reinitializes an object with
it. Construct the object before creating an unpack method.
The unpack method takes the saved state of the object and
reinitializes the object with it. It reinitializes the object members according
to the values in the container, taking the supplied version number into
account.
The method can return a Boolean that signals the result of the
initialization process.
26.
Architecture of MS dynamics AX.
Microsoft Dynamics is a unique and powerful solution which
contains efficient and flexible functional and development features. The
Microsoft Dynamics is a three tier Architecture.
The three tier architecture is defined as:
• Database:
For the purpose of storing data
• Server:
Responsible for running the application business logic
• Client:
Allows user to access data from the database and run the business logic on the
server
If we map this three tier architecture onto Microsoft AX, the
components can be defined as:
• Database
(SQL Server Database): Microsoft
Dynamics AX application uses data and data model stored in the SQL Server
Database.
• Server
(Application Object Server –AOS): The AOS runs the business logic of the
application.
• Client
(User Interface): The
end user accesses the application through the user Interface which is the
Microsoft Dynamics rich client or Enterprise Portal
SQL Server Databases:
• Microsoft
Dynamics AX Database: The Database is an online transaction
processing database which stores the business data, metadata and the
application code in tables and models.
• Business
Intelligence Database: SSRS
and SSAS Databases are involved
Application Object
Server:
As mentioned above, the AOS executes the business logic and perform many other
tasks such as running X++ Job, managing sessions and enforcing security etc.
Client:
• Microsoft
Dynamics AX Client: It is the primary client which is used to
access the functionality of the application. It is developed in the MorphX
environment and it is a rich client.
• Enterprise
Portal: Part
of the application that is displayed and accessed through a web browser
Some
of the other components which are an essential part of the Microsoft Dynamics
AX architecture are:
• Internet Information Server
• Microsoft Office
• The .NET Business Connector
• SharePoint
• Help Server
• Web Services
27.
Tell us about AIF(MSMQ).
Application Integration Framework (AIF) is the infrastructure
within AX with which you can expose business logic or exchange data with other
systems. AIF is comprised of three primary components:
1.Services -
Enable you to expose business logic written in X++ as a service to be consumed
by other applications. Within Microsoft Dynamics AX, you can create, customize,
and publish services.
2.Document services
- A specific implementation of services in which the Microsoft Dynamics AX
business logic is exposed through document services.
3.Consume Web
services - In Microsoft Dynamics AX, you can consume external Web
services from your X++ code.
28.
How to design a form in AX using X++?
The Form* classes enable you to manipulate, create, modify, or
run forms by using X++ code. You can also modify forms during run time so, for
example, one or more controls are hidden on a form, depending on the user's
selections in the preceding form.
The Form classes are all system classes and are prefixed with
Form.
Form, FormRun, FormDesign, FormBuildDesign, FormDataSource,
FormBuildDataSource, FormControl.
29.
How to create runtime query?
You can create a query to retrieve data by using the query classes.
Query, QueryRun, QueryBuildDataSource, QueryBuildRange,
QueryBuildLink, QueryBuildDynaLink.
30.
Difference between validate write and validate
field?
validateWrite():
Executed when a record is written to the database, before the data change is
committed in the database.
validateField():Executed
when you leave a field in a record. For example, after entering changes to a
field on a grid control, you could click another field in that same record or
on a different record. Or you could click another control on that same form.
The super() method invokes field validation checks, as guided
by the value of the Validate property.
31.
Do we have validate write and validate field in
form level?
FormDataSource –
validateWrite()
FormDataSourceField - validate()
32.
why do we use queries?
queries are user interactive, faster, compiles, reusable
components
query, queryrun,querybuilddatasource,querybuildrange
if(qr.prompt())
33.
What is cluster installation?
You can distribute the user load in Microsoft Dynamics AX
across multiple instances of Application Object Server (AOS) by creating a load
balancing cluster.
Cluster Over View:
Microsoft Dynamics AX offers two types of load balancing
clusters:
·
A cluster that includes a load balancer
·
A cluster that does not include a load balancer
34.
What’s
new in Dynamics AX 2012
SSAS - Analysis
service project wizard.
AOS - Validfrom and
validto columns, Unit of work class, Inheritance among the tables
Client -Form styles,
Search and parts
EP - Sharepoint
2010, listpge famework, windows live authentication
Morphe x - Models
and model store, dev. workspace, some layers renamed and powershell
SSRS – Labels in
reports, auto reports, cross reference can access, unlimited dimensions
X++ -Eventing, attributes, .Net proxies to X++ classes, faster compilation
35.
What are the architecture changes done in AX
2012 R2?
The model store and the transaction data are stored in separate
OLTP databases. In other versions of Microsoft Dynamics AX 2012 prior to
Microsoft Dynamics AX 2012 R2, the model store and transaction data are stored
in a single OLTP.
36.
What are Partitions? What is the purpose of
partitions in Microsoft Dynamics AX 2012 R2?
In the
glossary for Microsoft Dynamics AX, the formal
definition of a
partition is:
A
division of an application’s processing into logical or functional parts.
Partitions divide and isolate the business data of an
installation by using special processing that the AOS applies to data queries.
This special processing occurs immediately before the queries are sent to the
underlying Microsoft SQL Server database when a system field named Partition is present in a queried table.
Purpose of Partitions
The purpose of a partition is to
logically separate the data within its boundaries from the data in other
partitions. A partition enables the AOS to isolate the data in the partition on
users who are not authorized to access the data.
For example, a holding corporation might have several
subsidiaries or other legal entities. An installation of Microsoft Dynamics AX
for the corporation can have several partitions, perhaps one for each
subsidiary.
Relation between Legal Entities and Partitions
Each partition contains at least one company or legal entity. A
legal entity occurs in only one partition. When you create a legal entity, the
system assigns it to the current partition. The legal entity can never be moved
to another partition. However, its data can be exported from the partition and
then imported to another company in another partition.
37.
Table Keys: Surrogate, Alternate, Replacement,
Primary, and Foreign [AX 2012]
All keys are unique keys, meaning they disallow duplicate
values and null values.
Primary key:
A primary key is one type of key. The other type of key is an
alternate key. There is a maximum of one primary key per table, whereas a table
can have several alternate keys. The primary key is usually the type of key
that other tables, called child tables, refer to when a foreign key field in
those other tables need a relational identifier.
Starting in Microsoft Dynamics AX 2012 the primary key for
every new table is always enforced by an index that has exactly one field. The
one field is usually an incremented number or a completely meaningless number
that is generated by the system. For new tables the default is a primary key
based on the RecId field. This is represented as the surrogate key in the user interface.
The following table describes the PrimaryIndex property
and other major properties that are related to keys.
PrimaryIndex
The drop-down list contains the surrogate key plus every index
on the table that has its AlternateKey property set to Yes.
CreateRecIdIndex
This property controls whether the system creates a unique
index on the RecId field. The default value is Yes.
This is the basis of the surrogate key.
No other field is added to this index, not even DataAreaId.
ReplacementKey
The drop-down list contains every index that has its AlternateKey property set to Yes.
You might change the default blank value to an index whose
field values within each record provide a name or other moniker that is
meaningful to people. If a ReplacementKey is chosen, its fields can appear on forms to
helpfully identify each record.
The ReplacementKey should be a set of fields that represent the
natural key.
ClusterIndex
The ClusterIndex value is given to the
underlying Microsoft SQL Server database system as a performance tuning choice.
This choice generally controls the physical sequence in which the records are
stored in the underlying database.
Alternate Key
A table can have several alternate keys. Any one alternate key
can switch to being the primary key, if the alternate key is comprised of only
one field.
A table can reference the alternate key of another table.
However, it is more common for a table to reference the primary key of another
table. As an option, an alternate key can be chosen as the ReplacementKey of a table.
In practice each alternate key relies on a unique index for its
implementation and enforcement. However, a unique index alone does not make an
alternate key. TheAlternateKey property must be set to Yes to make a unique index be an alternate key.
The following table describes properties on the AOT node for an
index.
AllowDuplicates
No means that the
combined fields of the index must together make a value in each record which no
other record has.
AlternateKey
Yes means that other tables can create foreign
key relations that reference this key, as an alternative to referencing the
primary key.
Indexes with two or more fields cannot have their AlternateKey property value set to Yes.
ValidTimeStateKey
A key that is marked as a valid time state key is not a
candidate key for child tables to reference in their foreign key relations.
Instead, this key is meant for managing date effective data in its own table.
The default is No. This field can be Yes only if the ValidTimeStateFieldType property is Yes on the table. Yes means this key contains the ValidFromand ValidTo fields.
The ValidTimeStateKey property cannot be set to Yes when the AlternateKey property
is set to No.
ReplacementKey
A replacement key is an alternate key that the system can
display on forms instead of a meaningless numeric primary key value. Each table
can have a maximum of one replacement key.
The replacement key is chosen by setting the ReplacementKey property on the table. The drop-down list
offers every alternate key as an available value.
In Microsoft Dynamics AX, there are other terms that are used
to describe table keys. These terms do not appear as property names in
Microsoft Dynamics AX. These terms are described in the following table.
Foreign key
In Microsoft Dynamics AX, an AOT node under MyTable > Relations represents a foreign
key. For more information, see the previous Relations section in this
topic.
Natural key
A key whose value has meaning to people. Most replacement keys
are natural keys.
Surrogate key
A key whose value has no meaning to people. A large number
generated by the system, such as RecId, could be a surrogate key.
Unique key
A broad term that applies to primary keys and to alternate
keys. It does not apply to foreign keys. This term emphasizes that all values
for a given key must be unique within one table. All fields in a unique key
must be not-nullable.
38.
OOPs concepts?
Class: Class
is the 1st OOPs concept .Class defines the characteristics of objects which
includes its attributes, field’s properties and behavior. Let us say we have a
class called car, then the color, model number, top speed can be its attributes
and properties. Accelerating, breaking, turning will be its behavior.
Objects:
Objects can be considered as a thing that performs a set of related functions
.Programming objects are used to model real worlds objects. An object is also
an instant of a class, for our class Car, Ferrari will be our object
Instance: One
can have an instance of a class; the instance is the actual object created at
runtime. The set of values of the attributes of a particular object is called
its state. The object consists of state and the behaviour that’s defined in the
object’s class.
Method: Also
called as functions in some programming languages, methods defines the behavior
of particular objects. For our Car class, turning (), breaking () will be our methods.
Inheritance:
a parent class can inherit its behavior and state to children classes. This
concept was developed to manage generalization and specialization in OOP .Let’s
say we have a class called Car and Racing Car. Then the attributes like engine
no. , color of the Class car can be inherited by the class Racing Car. The
class Car will be Parent class, and the class Racing Car will be the derived
class or child class
Abstraction:
representing only the important details without including all the details. For example
the car Ferrari can be treated as simple car only.
Encapsulation:
The wrapping up of data and functions into a single unit is called as encapsulation.
For example the class car has a method turn () .The code for the turn ()
defines how the turn will occur. So we don’t need to define how Mercedes will
turn and how the Ferrari will turn separately. Turn () can be encapsulated with
both.
Polymorphism:
It’s an important OOPs concept, Polymorphism means taking more than one forms
.Polymorphism allows the programmer to treat derived class members just like
their parent class’s members. More precisely, Polymorphism in object-oriented
programming is the ability of objects belonging to different data types to
respond to calls of methods of the same name .If a Dog is commanded to speak(),
this may elicit a bark(). However, if a Pig is commanded to speak (), this may
elicit an oink (). Each subclass overrides the speak () method inherited from
the parent class Animal.
39.
Differences between MorphX & Intellimorph?
MorphX is the
Microsoft Dynamics AX IDE (Integrated Development Environment) which includes:
- Data Dictionary
- Tools for creating menus, forms and reports for Windows- and
Web clients
- Compiler and debugger for the object oriented programming
language X++
- Version control system
- Label (multi language text) systems
IntelliMorph is
the Runtime Environment embedded in Microsoft Dynamics AX that draws menus,
forms, and reports for Windows- and Web-clients with the correct contents,
size, and layout according to:
- The language your texts are displayed in.
- What features you can access.
- How wide you want the fields on your installation.
- The formats you are using for dates and numbers.
40.
RunBaseReport class
The RunBaseReport class makes all reports batchable and creates
a standard dialog box.
class RunBaseReport extends RunBaseBatch
This class is instantiated through the SysReportRun Class. It should be used by
all reports. The purpose of the class is to:
- Make all reports batchable
- Create a standard dialog
if you are creating more complex reports, it might be necessary to inherit from
this class. If this is the case, you must create the following methods:
lastValueElementName(). Returns the report name.
description(). Static.
main(). Static
41.
Difference Between Element & this
"this" can be used in any objects to reference the
current object and member methods.
MorphX forms and reports are composite objects.
In forms the collection of objects is contained within a
FormRun object. You can reference members in the outer FormRun object by using
the "element" reference.
If your code is placed at the top level there are no functional
difference between "this" and "element".
If your code is placed in a FormDataSource "this"
will reference the datasource but "element" will reference the
"FormRun".
42.
Difference Between COM & .NET Business
Connector
.NET Business Connector provides interoperability with the .NET
Framework. This is enabled by providing Windows Server SDK managed classes.
COM Business Connector provides Microsoft COM interoperability.
This is enabled by providing a Microsoft COM-based interface. COM Business
Connector is no longer going to be supported in Ax 2012
43.
Difference Between Primary key & Foreign key
Primary key is the
unique key of a table, for example ID.
Say, you have a student table, the primary key is usually
student id, as there won't be two students with the same id.
As for foreign key,
it's a key to define the relationship between two tables.
Say, there is another table called StudentEvent, which it
contains a PersonInCharge field.
In this StudentEvent table, the primary key is EventID, where
the PersonInCharge is actually storing the StudentID, which it is the foreign
key to the Student table. This actually defines the relationship between
Student table and StudentEvent table.
44.
Difference Between Construct & New methods
Method new () actually constructs a class and finalize ()
destructs.
Method construct () is a best practice to use when creating an
instance. In this method you code how to construct a specific class.
45.
Normal, field fixed & related field fixed
relations
Lets say you have ClothesTable and ClothesOrders.
ClothesTable has the following fields: ClotheId, Name and
CollectionTypeId
MenClothesOrder has the following fields: OrderId, ClotheId,
Qty OrderId could be a number sequence and Qty entered manually by the user.
CollectionTypeId has the following elements:
0 - Men
1 - Women
2 - Children
Example 1: Related Fixed Field
On MenClothesOrder we create a new relation to ClothesTable and
specify the follwing two:
1. Normal = ClotheId to ClotheId (Best practice to specify this
on the EDT) and
2. Related Fixed Field 0 = ClothesTable.CollecTionTypeId
This shows that the lookup to the clothes table should show
only clothes with the same ClotheId (point 1) AND clothes that are of type Men
(point 2) because the table deals with order for mens' clothes. We use 0
because Men is element 0 in the Enum.
Example 2: Fixed Field
This kinda works the other way round:
Imagine you have a ClothesOrders table (generic) and you have
seperate tables for MenClothesTable, WomenClothesTable and
ChildrenClothesTable. Fixed field says that the specified normal relation (on
ClotheId) to MenClothesTable only works if the CollectionTypeId of the current
record is set to 0 (Men) else the relation is disabled.
46.
Difference Between Table & View in AOT
Table:
Relational Database is composed of tables that contain related data.
View:
1. Views are created from one or more than one table by joins,
with selected columns.
2. Views are created to hide some columns from the user
3. Views reduces the effort for writing queries to access
specific columns every time.
4. View doesn't contain any data.
47.
Refresh(),reread(),research() &
executeQuery()-
1. Refresh
This method basically refreshes the data displayed in the form
controls with whatever is stored in the form cache for that particular
datasource record. Calling refresh () method will NOT reread the record from
the database. So if changes happened to the record in another process, these
will not be shown after executing refresh ().
2. refreshEx
This method should be used sparingly, in cases where multiple
rows from the grid are updated, resulting in changes in their display Options,
as an example. So you should avoid using it as a replacement for refresh (),
since they actually have completely different implementations in the kernel.
3. Reread
Calling reread () will query the database and re-read the
current record contents into the datasource form cache. This will not display
the changes on the form until a redraw of the grid contents happens
4. Research
Calling research() will rerun the existing form query against
the database, therefore updating the list with new/removed records as well as
updating all existing rows. This will honor any existing filters and sorting on
the form that were set by the user.
5. Execute Query
Calling executeQuery () will also rerun the query and
update/add/delete the rows in the grid. The difference in behavior from
research is described below.
ExecuteQuery should be used if you have modified the query in
your code and need to refresh the form to display the data based on the updated
query.
48.
FormDataSource.queryRun().query() &
formDataSource.query()-
An important thing to mention here is that the form has 2
instances of the query object - one is the original datasource query (stored in
formDataSource.query ()), and the other is the currently used query with any
user filters applied (stored in formDataSource.queryRun ().query ()).
When the research method is called, a new instance of the
queryRun is created, using the formDataSource.queryRun ().query () as the
basis. Therefore, if the user has set up some filters on the displayed data,
those will be preserved.
This is useful, for example, when multiple users work with a
certain form, each user has his own filters set up for displaying only relevant
data, and rows get inserted into the underlying table externally (for example,
through AIF).
Calling executeQuery, on the other hand, will use the original
query as the basis, therefore removing any user filters.This is a distinction
that everyone should understand when using research/executeQuery methods in
order to prevent possible collisions with the user filters when updating the
query.
1.
Difference
between model and model store
Basic Info:
Models were introduced in Microsoft Dynamics AX
to help partners and customers more easily install and maintain multiple
solutions side by side in the same layer. This topic introduces the concept of
models, and describes how models relate to layers and label files. This topic
also describes the model store, which is the part of the Microsoft Dynamics AX
database in which models are stored.
Models:
A model is a set of elements in
a given layer. Each layer consists of one or more models. Each layer contains
one system-generated model that is specific to that layer. Every element in a
layer belongs to only one model. In other words, no element can belong to two
models in the same layer, and every element must belong to a model.
A model is permanently associated with the
layer that is created in. If you need to move one of your models from one layer
to another, you must create a project from the model in the AOT, export the
project as an xpo file, create a target model in the desired layer, delete the
original model to avoid having to resolve layer conflicts, and import the xpo
file to the target model. If you are moving elements between models in the same
layer, you can use the Move to model command in the AOT.
ModelStore:
Models are stored in the model store.
The model store is the part of the Microsoft Dynamics AX database in which all
application elements for Microsoft Dynamics AX are stored. Customizations are
also stored in the model store. The model store replaces the Application Object
Data (AOD) files that were used in earlier versions of Microsoft Dynamics AX.
Models that have been installed in the model store are used at run time.
Note: Models can be
exported to files that have the .axmodel extension. These files are called
model files. Model files are deployment artifacts. Model files can be signed
with strong name signing and Microsoft Authenticode signing.
How to manage Label files with Model:
In Microsoft Dynamics AX 2012, label files, or
ALD files, are part of models. A label file must be added to a model before the
model can be installed. After a model has been installed, ALD files are pulled
from the model store to the local of Application Object Server (AOS) instance
when the AOS is started. When the AOS is shut down, the ALD files are pushed
back to the model store.
ALD files from earlier versions of Microsoft
Dynamics AX are not part of a model file. However, you can import these files
into the model store from the Label Files section of the
Application Object Tree (AOT). Use the Create from file shortcut
command.
Note: The ALD file
from an earlier version of Microsoft Dynamics AX must not be located in the
application folder of AOS. Otherwise, you cannot import the file.
Working with label files across solutions
It is recommend that you use one label file
per solution to simplify installation.
If you find that you require multiple label
files, it is recommend that you create a single shared, cross-solution label
file and package it as a model file. Then, when you install solutions, you must
install two models: the solution itself and the label model.
If you want to ship additional languages, you
can add the languages to the solution model, increment the model's version
number, and then reimport the model.
