While you can use type 2 SCDs (and any other implementation of an SCD) in SSAS, it is not the thing that implements them.
You need to implement them in a Datamart/Datawarehouse and SSAS will then read them from there. What might be of interest to you is the Slowly Changing Dimension task in SSIS. It's not the quickest of components, but it does allow you to use a GUI to define the columns that you want to tracking history on.
When i use the crystal report, there have a option "push" & "pull" .
Does report in the SQL Server reporting Services have the same option ?
Thank you!With Reporting Services, you can subscribe to reports and also generate on-demand and data-driven reports. Is this the push and pull functionality you are looking for?|||
Not. In crystal report , use push mode need get the data by user not by the crystal report, the fill the data into the report. So this mode can improve the performance.
If there is large data in the database , use pull mode wil very slowly.
Thank you for your reply.
|||Hi, does anyone knows how to this? I also need to push the data to the report because I have this scenario, I have to display a report on the changed data of the user (not yet being saved in the database). How could this be done in the reporting services?
Thanks a lot in advance and more power.
When i use the crystal report, there have a option "push" & "pull" .
Does report in the SQL Server reporting Services have the same option ?
Thank you!
With Reporting Services, you can subscribe to reports and also generate on-demand and data-driven reports. Is this the push and pull functionality you are looking for?|||
Not. In crystal report , use push mode need get the data by user not by the crystal report, the fill the data into the report. So this mode can improve the performance.
If there is large data in the database , use pull mode wil very slowly.
Thank you for your reply.
|||Hi, does anyone knows how to this? I also need to push the data to the report because I have this scenario, I have to display a report on the changed data of the user (not yet being saved in the database). How could this be done in the reporting services?
Thanks a lot in advance and more power.
Hi there,
In a lot of the Replication documentation it only refers to the merge agent operating in the context of a push or a pull configuration. i.e. if it is push then the merge agent is at the distributor but if it is a pull then the merge agent functions at the subscriber.
I recently joined a project which is configured as a push but it uses RMO for synchronisation. This RMO application is installed on a compeletely separate server. Initially I thought the RMO was just passing requests through to the publisher/distributor/subscriber but the distributor didn't seem to be doing any of the work. It therefore seems that the merging/synchronisation is being performed on this RMO application server and not the distributor or subscriber.
I therefore think it would be good (assuming I am correct of course) that the documentation reflects this caveat
As a general observation Replication programming seems to be quite detached from the rest of the replication documentation. Is this a deliberate decision?
It isn't normally, but I'll ping the writer in charge of this and ask.
Buck Woody
|||
To answer your last question first. Yes, it was a product-wide design decision to put all of the programming API documentation for SQL Server together in a separate node. I agree with you that it isn't ideal. In the next release of SQL Server, we will include the programming content for each component with the rest of the component's conceptual content.
There is no general requirement that an RMO application run on a replication server. SQL Server Management Studio (SSMS) uses RMO to perform administrative tasks in replication, and you can administer replication on remote servers using SSMS. You can also synchronize subscriptions remotely using RMO (MergeSubscription.SynchronizeWithJob in the case of a push subscription), which runs the agent job on the Distributor to asynchronously start the Merge Agent. To run the Merge Agent synchronously (MergeSynchronizationAgent.Synchronize) and receive callbacks (synchronization status events), your application needs to run on the same server as the Merge Agent (the Distributor in your case).
I will see if we can make the RMO documentation more clear on this point.
Best wishes,
Glenn Gailey [MSFT]
SQL Server UE
|||Hi Glenn & Buck,
Thanks very much for getting back to me.
I am glad to hear that the API docs will be more integrated in katmai.
On the other point I am a little confused. In our setup the merge application using RMO runs on a totally separate server to the distributor but this third machine (distributor is remote to the publisher) has SQL Express installed. We get back all the callbacks and replication is operating. I mention this because I think this kind of setup isn't really referred to in BOL but I also believe it is a permissable setup (although not perhaps a very common one).
Cheers, James
|||Is your RMO application running on the Subscriber server, or on a 4th server totally outside the Pub/Dist/Sub topology?|||It sits on a completely separate 4th server.
Cheers, James
|||I checked with the development team, and it is possible to run the Merge Agent remotely (both synchronously and asynchronously) using RMO. I will look into providing this information in the documentation.
Cheers!
|||Is it possible to run application that uses RMO on a server without installing SQL server? From the posts in this thread I assume the 4th server has SQLServer Express 2005 installation just to be able to run RMO app.|||That is correct. You do need to have at least sql express installed. This is the only way to get the RMO components onto the server.
Cheers, James
Hi there,
In a lot of the Replication documentation it only refers to the merge agent operating in the context of a push or a pull configuration. i.e. if it is push then the merge agent is at the distributor but if it is a pull then the merge agent functions at the subscriber.
I recently joined a project which is configured as a push but it uses RMO for synchronisation. This RMO application is installed on a compeletely separate server. Initially I thought the RMO was just passing requests through to the publisher/distributor/subscriber but the distributor didn't seem to be doing any of the work. It therefore seems that the merging/synchronisation is being performed on this RMO application server and not the distributor or subscriber.
I therefore think it would be good (assuming I am correct of course) that the documentation reflects this caveat
As a general observation Replication programming seems to be quite detached from the rest of the replication documentation. Is this a deliberate decision?
It isn't normally, but I'll ping the writer in charge of this and ask.
Buck Woody
|||To answer your last question first. Yes, it was a product-wide design decision to put all of the programming API documentation for SQL Server together in a separate node. I agree with you that it isn't ideal. In the next release of SQL Server, we will include the programming content for each component with the rest of the component's conceptual content.
There is no general requirement that an RMO application run on a replication server. SQL Server Management Studio (SSMS) uses RMO to perform administrative tasks in replication, and you can administer replication on remote servers using SSMS. You can also synchronize subscriptions remotely using RMO (MergeSubscription.SynchronizeWithJob in the case of a push subscription), which runs the agent job on the Distributor to asynchronously start the Merge Agent. To run the Merge Agent synchronously (MergeSynchronizationAgent.Synchronize) and receive callbacks (synchronization status events), your application needs to run on the same server as the Merge Agent (the Distributor in your case).
I will see if we can make the RMO documentation more clear on this point.
Best wishes,
Glenn Gailey [MSFT]
SQL Server UE
|||Hi Glenn & Buck,
Thanks very much for getting back to me.
I am glad to hear that the API docs will be more integrated in katmai.
On the other point I am a little confused. In our setup the merge application using RMO runs on a totally separate server to the distributor but this third machine (distributor is remote to the publisher) has SQL Express installed. We get back all the callbacks and replication is operating. I mention this because I think this kind of setup isn't really referred to in BOL but I also believe it is a permissable setup (although not perhaps a very common one).
Cheers, James
|||Is your RMO application running on the Subscriber server, or on a 4th server totally outside the Pub/Dist/Sub topology?|||It sits on a completely separate 4th server.
Cheers, James
|||I checked with the development team, and it is possible to run the Merge Agent remotely (both synchronously and asynchronously) using RMO. I will look into providing this information in the documentation.
Cheers!
|||Is it possible to run application that uses RMO on a server without installing SQL server? From the posts in this thread I assume the 4th server has SQLServer Express 2005 installation just to be able to run RMO app.That is correct. You do need to have at least sql express installed. This is the only way to get the RMO components onto the server.
Cheers, James
