Differences among reread(), refresh(),research()

Differences among reread(), refresh(),research()

When working with Forms, commonly after opened the form we need to do some operations with existing data. In few cases we need to interact with data base again and again in order to do. For that we will use these methods. But some times its create confuse what exactly use of these methods, when should we call these methods and why, here is brief info these methods...

refresh() : this method will refresh the data in the data source cache. But it will not interact with the data base to fetch the new/updated record values. What ever values have fetched in the previous query will store in data source cache, this method will just refresh the data source cache only.

reread(): this method will interact with the data base and runs the query against the data base in order to fetch the new/updated record values. But this will not show the updated values in the form until calling the refresh method. that means it will update the data source form cache only but not existing form control values.
So it is better to call the methods as shown here, like reread and after refresh methods in order to fetch the new / updated values from the data base.

formDataSource.reread()
formDataSource.refresh()

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.

- Harry

How to get the current database name in axapta

How to get the current database name in axapta

Here is a small trick to know the name of current data base in axapta.

Axapta supports a class called SysSqlSystemInfo by using this class we can get the current database name...

To do this just create a new job and write following code or you can copy paste from here also.

static void sqlSysName(Args _args)
{
    ;
    info(SysSQLSystemInfo::construct().getloginDatabase());
}

- Harry

Document Handling in Microsoft Dynamics AX

Document Handling in Microsoft Dynamics AX 2009 and 2012

Document Handling is very useful to attach files related to AX data to forms. It’s possible to add data at any form. It is also useful to attache any reference document to any record in Form.
To use Document Handling you have to activate it by follow these steps...

To activate this feature follow the next steps:

1. Go to Basic – Setup – Document management:


2. Setup Parameters:


Active directory is the default path where allocate the files to attach.
Check Use Active document tables has to be activated.


Number sequence to numerate the attachments.
3. Define Document types:


For each type it’s necessary define the location folder:


4. Select in which forms it’s possible to attach documents in Active document tables:




5. Now, we can attach documents in the above forms. For example in Employees form:




For this example, we are going to attach a Photo:


Select the photo and click open:



With the check Show file activated we can see the photo/document:


Also, we can open the document with the right button Open.

-Harry

Types of delete action

Types of delete action

In Table node there is a sub node called "Delete Action". In axapta there is mainly three type of delete action. Each of them have their own specific use. Here is the simplest defination for each of them.

Cascade

A cascading deletion action will delete all records in the related table, where the foreign key is equivalent to the primary key of the current table. That is, deleting the parent record will also delete the child record(s) in the related table.
This cascading will take place whether the deletion is performed in code or directly by a user through the user interface.

Restricted

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

This delete action normally works as a Restricted delete action. However if the deletion is performed through X++ code, no error will be raised and the deletion will be cascaded to the related table.


for more details on delete action follow these links

• How to Create A Delete Action
• Dilemma of delete actions- Restricted/Casecade+Restricted
• Example: Delete Action

- Harry