Well this topic is dead, or at least it will be after this post.
I wrote about this topic just prior to The Crystal Report Writing class. During the class the question was asked
“What about using the Execute SQL tool in the SalesLogix Administrator for syncing out SQL views to remotes?”
As a development team we have looked at this before and always found that it just did not work. But we had not tested it in quite a while so we decided to try it again, and this time it worked.
So here for the final time as a topic on the Report Writing blog is the “Best way to Sync SQL views out to Remotes”.
To accomplish this we need a SQL view. A SQL view for those who do not know is an excellent way of organizing data for a report. When your view is complete the view will act like a database table. The biggest issue with using SQL views in reports is the Remote database issue. Just creating a view in SQL does not synchronize it out to the SalesLogix Remote Databases.
Here is a simple SQL selected statement that counts records related to an Account.
SELECT a.ACCOUNTID, a.ACCOUNT, COUNT(c.CONTACTID) AS ContactCount,
(SELECT COUNT(HISTORYID) AS Expr1 FROM sysdba.HISTORY WHERE (ACCOUNTID = a.ACCOUNTID)) AS HistoryCount,
(SELECT COUNT(ACTIVITYID) AS Expr1 FROM sysdba.ACTIVITY WHERE (ACCOUNTID = a.ACCOUNTID)) AS ActivityCount,
(SELECT COUNT(OPPORTUNITYID) AS Expr1 FROM sysdba.OPPORTUNITY WHERE (ACCOUNTID = a.ACCOUNTID)) AS OpportunityCount,
(SELECT COUNT(TICKETID) AS Expr1 FROM sysdba.TICKET WHERE (ACCOUNTID = a.ACCOUNTID)) AS TicketCount
FROM sysdba.ACCOUNT AS a LEFT OUTER JOIN
sysdba.CONTACT AS c ON a.ACCOUNTID = c.ACCOUNTID
GROUP BY a.ACCOUNTID, a.ACCOUNT
To make it a view we add the text of:
CREATE VIEW sysdba.vACCOUNCOUNTs
AS
This is entered right above the select statement.
When you combine the view with other tables we can get some excellent roll up information.
This data can even be used with the group builder in SalesLogix
To get this view synchronized out to the remotes, log into the SalesLogix Administrator.
Once the interface is open use the Tools> Execute SQL menu selection to open the Execute SQL tool.
When the Execute SQL interface opens, right click and select Add from the list that appears.
When the Edit SQL view appears copy in the SQL View you wish to synchronize out.
When you are ready, select OK. You are returned to the Execute SQL interface.
Next we must identify the users who will receive this view. On the lower half of the Execute SQL interface we see a list of names on the Left, find and highlight the name of the people the view should be synchronized out to and select the right pointing arrow.
Once all of the target users are selected, click on the “Execute” button on the upper right side of the view.
You will receive the following message box. Simply click on the “Yes” button….
….and the SQL Script will run.
Select OK and close out of the SalesLogix Administrator.
The next time the Sync Serve Synchronizes it will pick up the view and ship it off to your selected users.
A lot easier then writing all of that script. God Bless.
Geo
Good post George,
The BIG caveat with this method, and the reason why this hasn’t worked in the past, is that the SQL statement that makes up the view can fail to be parsed by the SLX provider when the SQL starts to get complicated (which often in the case for a view).
When you execute this via the Execute SQL in the SLX Administrator, the query is parsed and executed via the SLX OLEDB Provider. The provider parses apart and reconstructs all statements that go through it. It does this for many reasons, but primarily to log operations and mainly to be able to determine security for the user it is being executed for, meaning, does the user have access to the data being retrieved in the query. If the SQL is complex enough then the SLX Provider will fail when it attempts to parse the statement. This is what has always been the problem in the past with this method.
Over time, the SLX provider’s capabilities to parse complex SQL has improved significantly. It likely also, in newer versions at least, might even now parse statements differently that begin with CREATE VIEW (at least I hope it does). This is why this works now in recent versions better than this method did in the past. I would suspect that if the statement for the view became complex enough that you might still run into issues with this method, and it would certainly not work in most cases in older versions of SLX (again, due to the SLX provider capabilities of those prior versions).
In your previous post, the capabilities, or lack of, in the SLX provider did not have any impact on the creation of the view, even with the view’s SQL statement was complex. This is because the previous method you outlined didn’t execute the view via the SLX provider and instead used a native SQL connection to the database and bypassed the SLX provider altogether.
Anyway, just wanted to chime in with some of the reasons for this.
-Ryan
If you then cut a new database for a user, will the view propagate or will it have to be re-distributed every time a new database is cut.
See this post https://customerfx.com/article/sync-views-out-to-remotes/