Friday, 11 May 2018

XRM Javascript


All Basic XRM javascripts code:

Xrm.Page.data.entity attribute



https://msdn.microsoft.com/en-us/library/gg334409.aspx#BKMK_addOnChange





Thursday, 10 May 2018

XRM Toolbox Plugins



XRM Toolbox Plugins


  • Portal Code Editor, to add/edit javascript for portal pages.
  • Early bound Generator. to generate early bound classes for Entities and option lists.



Set Up StyleCop to check code style violations in Visual Studio

What is StyleCop?

StyleCop is an open source static code analysis tool that runs in Visual Studio, checking for code style violations. The default rules were established by consolidating the preferences of various teams across Microsoft and are designed to emphasize readability and maintainability of C# code, but users can also customize their own rules.
More details to setup is at:
https://blog.redbluegames.com/how-to-set-up-stylecop-in-unity-b3ca908211d9



Configure Web form subgrids for portals



Configure Web form subgrids for portals



Steps to display clickable grid on portal;

1: Create a view on the entity in dynamics administration.
2: Create a Entity Form on the Portal Administration.
3: Go to the Web Form step and add Web Form Metadata.
4: In Web Form Metadata window select option Grid and select the Entity form created at step 2.
5: Set send user's detail as Query String.
6: Save it and refresh cache.




Custom Work Flow Basic concepts in Dynamics 365

Monday, 31 October 2011

How Database Snapshots Work


How Database Snapshots Work

A database snapshot provides a read-only, static view of a source database as it existed at snapshot creation, minus any uncommitted transactions. Uncommitted transactions are rolled back in a newly created database snapshot because the Database Engine runs recovery after the snapshot has been created (transactions in the database are not affected).

Database snapshots are dependent on the source database. The snapshots of a database must be on the same server instance as the database. Furthermore, if that database becomes unavailable for any reason, all of its database snapshots also become unavailable.

Snapshots can be used for reporting purposes. Also, in the event of a user error on a source database, you can revert the source database to the state it was in when the snapshot was created. Data loss is confined to updates to the database since the snapshot's creation. Also, creating a database snapshot can be useful immediately before making a major change to a database, such as changing the schema or the structure of a table. For more information on the uses of snapshots, see Typical Uses of Database Snapshots.

Understanding how snapshots work is helpful though not essential to using them. Database snapshots operate at the data-page level. Before a page of the source database is modified for the first time, the original page is copied from the source database to the snapshot. This process is called a copy-on-write operation. The snapshot stores the original page, preserving the data records as they existed when the snapshot was created. Subsequent updates to records in a modified page do not affect the contents of the snapshot. The same process is repeated for every page that is being modified for the first time. In this way, the snapshot preserves the original pages for all data records that have ever been modified since the snapshot was taken.

To store the copied original pages, the snapshot uses one or more sparse files. Initially, a sparse file is an essentially empty file that contains no user data and has not yet been allocated disk space for user data. As more and more pages are updated in the source database, the size of the file grows. When a snapshot is taken, the sparse file takes up little disk space. As the database is updated over time, however, a sparse file can grow into a very large file. For more information about sparse files, see Understanding Sparse File Sizes in Database Snapshots.


Service Principal Names

service principal name (SPN)



A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.
Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account object that the service instance uses to log on. A given SPN can be registered on only one account. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.