Formdatasource (1)

Overview
As an intermediate object for data storage and presentation, formdatasource plays an important role in form. It can be said that it understands the methods and events in formdatasource and master most of form content. this article attempts to explain the main methods and attributes of formdatasource.
As the help document of dynamics axapta is still being improved, some of the explanations in this article come from your own tests and may not fully reflect the intent of the designer. I also hope to see more comments from colleagues in this article.
Data Access
As axapta's platform core Code The code of the formdatasource method cannot be seen or tracked, so it cannot know its internal processing logic. However, you can still use existing tools to explore its principles, for the data access layer, we can use the SQL tracking tool provided by axapta to view the SQL statements it executes to speculate on how to set SQL tracking. I will not go into details here.
Here, we use a simple example to illustrate how to create a form custtabletest, set its data source to custtable, create a grid in design, and drag the accoutnum and name fields of custtable to the top.
Click Properties of the data source to view the following attributes related to data capture:
1. autoquery
Explanation:
The formdatasource class has a query method. The prototype is as follows:
Public final query ([query _ value])
Axapta provides two ways to access the database for formdatasource: Query and SQL, of course, both methods are executed through the formdatasource excutequery method. If the object returned by the formdatasource query method is instantiated, queryrun is called to implement the query, if not, data source-related statements are directly used for query. (This document does not provide relevant information. You can view the generated SQL statements by tracking them.
If the autoquery attribute is set to yes, the SQL statement run on the form custtabletest is as follows (fields in the customer table are represented by * to save space ): User ID: Admin
Time: 15 : 06 : 12   2006 - 12 - 29
Version: Microsoft Business Solutions - Axapta 3.0 (Build Number   1951.4060 )
Database : Microsoft SQL Server
SQL statement: Select   *   From Custtable Where (Dataareaid = ?) Order   By A. dataareaid, A. accountnum Option (Fast 1 ) [ Id = 12, reused = Yes ]
Call Stack:
\ Classes \ queryrun \ Next
\ Classes \ formdatasource \ executequery

As you can see, axapta uses the queryrun object to query data.
If you set autoquery to no, the executed statement is as follows: User ID: Admin
Time: 15 : 08 : 58   2006 - 12 - 29
Version: Microsoft Business Solutions - Axapta 3.0 (Build Number   1951.4060 )
Database : Microsoft SQL Server
SQL statement: Select   *   From Custtable Where (Dataareaid = ?) Order   By A. dataareaid, A. accountnum Option (Fast 1 ) [ Id = 15, reused = No ]
Call Stack:
\ Classes \ formdatasource \ executequery

As you can see, axapta does not use the queryrun object to query data, but directly uses excutequery to query data.
Of course, axapta's BP said that this autoquery must be set to yes. However, after learning about its principle, there is no need to limit it. At the beginning, the designer exposed this switch and had his intention. it is inconvenient to construct a query by using the query object structure to implement complex queries.
There is a problem here: when using the query, it is easy to guess that the excutequery method constructs a queryrun using the query object and then executes the query, if we do not use query to construct a query, how can we directly use keywords such as select from to construct a query? How does excutequery know what SQL statements should be executed? Unable to see excutequery Source code I can only guess.
Set the autoquery attribute of the data source to no and add the following code in the init method of the data source custtable: Public Void Init ()
{
Super ();
Select Accountnum, name From Custtable
Where Custtable. accountnum =   ' 4000 ' ;
}

Open the form and view the executed SQL statement: User ID: Admin
Time: 15 : 22 : 03   2006 - 12 - 29
Version: Microsoft Business Solutions - Axapta 3.0 (Build Number   1951.4060 )
Database : Microsoft SQL Server
SQL statement: Select A. accountnum, A. Name, A. recid From Custtable ( Index (I _077accountidx )) Where (Dataareaid = ?) And (Accountnum = ?)) Order   By A. dataareaid, A. accountnum Option (Fast 1 ) [ Id = 3, reused = No ]
Call Stack:
\ Forms \ custtabletest \ data sources \ custtable \ Methods \ init - Line 4

User ID: Admin
Time: 15 : 22 : 03   2006 - 12 - 29
Version: Microsoft Business Solutions - Axapta 3.0 (Build Number   1951.4060 )
Database : Microsoft SQL Server
SQL statement: Select A. accountnum, A. Name, A. recid From Custtable ( Index (I _077accountidx )) Where (Dataareaid = ?) And (Accountnum = ?)) Order   By A. dataareaid, A. accountnum Option (Fast 1 ) [ Id = 4, reused = No ]
Call Stack:
\ Classes \ formdatasource \ executequery

We can see the second SQL script. The SQL statement executed in excutequery is actually the one executed in init.
From this we can guess that as long as the init method of the data source (or somewhere else, it can be done before the excutequery) define an SQL statement (which can contain any other table and any complicated query ), of course, the premise is that this SQL statement must contain the table variables with the same name as the current data source (such as custtable in this example). This SQL statement will be executed when excutequery is executed, as for its logic, I haven't figured it out for half a day. According to the document, custtable is equivalent to formdatasource. the current record of the physical table referenced by cursor and datasource. Why can excutequery execute the SQL statement defined in init.
There is another problem here, of course, we do not want to execute the same SQL statement twice. How can we make the init method define a query executed in excutequery without executing the query action in the init method? This may be the reason why nofetch is a keyword in X ++. When I read the document, I always wanted to use such a strange keyword? Since no query is currently executed, when will the query be executed? Why save the country? Here, nofetch is useful. Modify the method defined in init as follows: Public   Void Init ()
{
Super ();
Select nofetch accountnum, name from custtable
Where custtable. accountnum= '4000';
}

In this way, when you look at the executed SQL script, it will only be executed once in excutequery. define the SQL script to be executed in the init method and then execute it in the excutequery method. Maybe this is the intention of nofetch?
Application scenarios:
In most cases, this attribute should be set to Yes according to the requirements of BP. However, if the query to be constructed is complex and involves many tables, it is difficult to construct the query, you can set it to no, and then use the X ++ keywords such as select in the init method to construct the query.
2. autosearch
Explanation:
This attribute indicates whether to execute the formdatasource excutequery method when loading the form for the first time. If it is set to yes, the formdatasource excutequery method will be called in the run method of formrun, otherwise, it is not called. Because the formdatasource data is obtained through the excutequery method, not calling this method means that the form will not load any data.
Application scenarios:
In most cases, set this attribute to Yes according to the requirements of BP. Remember to write ASP. NET Program In order to speed up loading data on the page, data is not loaded when loading the page for the first time. When the user selects a condition and clicks the button, the data is relatively less loaded, the speed is faster. If you have such a requirement, you can set this attribute to No.
3. onlyfetchactive
Explanation:
What is active? Is the field to be displayed on the form. this attribute indicates whether to capture only the data to be displayed on the form, but this benefit is only available when autoquery is set to yes, if you construct a query by yourself or query through SQL, you will not be able to enjoy this treatment, because axapta knows what you are doing?
In addition, set this attribute to yes. To maintain data consistency, axapt does not allow you to delete the records. If you forcibly Delete the records, it will give you an error see.
Application scenarios:
This attribute is tailored for the lookup form. Because you only need to query the fields to be displayed from the database, the speed will undoubtedly increase a lot. if there is no special reason for a normal form, we recommend that you do not change this attribute so that it is no by default.