In reply to: Account deleted
Hi Daniel
Well, the main reason why I am using SQL views in some places is because I can't get the results I need with a BPS internal views. With the standard filters I can't filter for what I need (because you cannot run functions in standard filters - if you can so, I haven't found any information about it).
AND, there are actions for which it is not possible to use BPS internal views at all, but an SQL query *is* expected.
Example are the two actions from 'Database retention', where there is no possibility to use a BPS internal views.
Using the SQL views was originally recommended to me by an (other) MVP... 😅
Best regards,
Roman
Hi Roman,
as the BPS internal view would only have a benefit if it's used for fields/attributes. The date time values are in the correct format for the user and the like.
Back to your situation. There are two reasons when I would use, my own, views.
1. I need to use a function which is not supported, when the sql query is written in the Designer studio. For example if I need to use ROW_Number() which requires an order by.
2. As far as I remember, the SQL server can improve the performance for executed views.
If neither of the options above are required, I would either use MSSQL database data source or just write the query where it is used. In one attachment you see the "conversion" of a generated process view to a MSSQL database data source.
It just occurred to me, that you may talk about different views. I hope I didn't make a wrong assumption. :)
It's also worth to note, that the data source has a standard and an advanced filter option, see the other screenshot. I've only used the advanced a handful of times.
As you will notice in the "Show" view of the expression editor, not even the data sources use the process views.
Slightly off topic:
I once created a process to transfer these scripts using a dictionary, but I haven't tested them in a long time.
https://github.com/Daniel-Krueger/webcon_artifactDeployment/tree/main/2021.1.3.205
Best regards,
Daniel