Page History

...

The first method you can use is the WhereCondition. In this case, the data query will be performed in a table, created at Edit > Datasets > Tables. Since the table is already selected, you only need to supply the conditional. You must also run SelectCommand to update the query.

Method 2: Query

The second method is similar to the first one, but it uses a query, created at Edit>Datasets>Queries and linked to a provider (see image below).

...

@Dataset . Query . Query1 . Sql Statement = ” s e l e c t ? from Table1 where 
UTCTimestamp  Ticks>=”  +  StartTime . Utc Ticks  +  ”   and   UTCTimestamp  Ticks<=”  +
EndTime . Utc Ticks + ”” ;
@Tag . TableTag = @Dataset . Query . Query1 . SelectCommand () ;

Method 3: Different Location

...

The last option is to use a feature called a SQL Query Builder, found at Edit>Datasets. It is a graphic interface that facilitates the creation of SQL Statements based on a specific provider. This method is not as usual as the others, so more details regarding its functionalities will be explained below.

Appendix A

For the SQLStatement, which is a property of the Query, and for the WhereCondition, which is the property of the Table of the Dataset, you can customize your query in the database, they are properties of type server, so if you modify this property via Script , either on the server or on the clients, the property value will be synced between all clients.

However, we created the possibility for the user to configure Client Tags in the configuration of these properties, for example:

String1: Select * from {tagTable} where {tagWhereCondition}

Where, "tagTable" and "tagWhereCondition" are Client tags.

Note that String1 will always be the same, not being modified in the scripts, what will change is the tags of type Client. When we execute the SelectCommand or SelectCommandWithStatus methods, we resolve these tags in the client's context, passing to the server to correct the right query. Multiple clients can use the same query or table without conflict. Although, they will still be entering the same execution queue on the server (this does not mean multithreading).

To summarize, you could even just put a { tagSQLStatementClient } in the SQLStatement, and the content of the query would be what was in that tag, specific to each client. It is important to remember that in this way it makes no sense to use the Select and Next properties, as they are only for server execution.

...

How to use SQL Query Builder

...