Posts Tagged ‘Database’

Dear all,

With LightSwitch, currently you can consume different data source types:


  • Database
  • SharePoint
  • WCF RIA Service

So far, so good. Upon a fresh installation, I set up a custom list. The goal was to consume the SP2010 list in a LightSwitch Application, as a data source. Using the Add Data Source wizard, I came until I entered the server address and my credentials on the server. Then, the Choose Your SharePoint Items window issued a message like:




With the small but all-telling message that what we need is a running SP2010 with the WCF Data Services installed. Obviously, I didn’t have this installed, so I went to install (as recommended) the CTP2 of the ADO.NET Data Services v1.5. In the good hope that it would work now, I tried again – but not a chance. I tried also to access the data services via browser, but this way it would issue only the following message:




Again, not a chance. So, I went for installing the following:


ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows 7 and Windows Server 2008 R2


Since I am running Windows Server 2008 R2 on my VM, I took the choice above. If however you are running a different OS than the ones mentioned above, you might want to have a look at the following link:


ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows 2000, Windows Server 2003, Windows XP, Windows Vista and Windows Server 2008


And here we went! Adding a datasource using LightSwitch, I got the a list of all available SP lists, as expected, and could add them as a datasource. One more thing that was bothering: When defining a custom list, specifying a column of type




Then LightSwitch Beta1 will import this list as a table where the column of type Number is always of type Double. Also, changing the list column type to number with 0 decimals won’t change this behaviour. Obviously, if then we try to create relationships in LightSwitch with tables from other data sources, we have a problem. I hope there exists a workaround for this not-so-much-desirable behavior.

Important notice: Before installing the above mentioned ADO.NET Data Services Update, please consider that the server will need to be restarted for the changes to take effect!

If you install the data services AFTER your SP2010 installation, then you might also to run the iisreset command. Of course, running all the installations and commands mentioned require attention and contain potential harms that are to be carried out at your own risk.


I wish you happy Lightswitching and SharePointing till the next time! 😉


Best regards,


Read Full Post »

Hi all,

After a fresh installation (or upgrade from a MOSS 2007), there are a couple of configuration steps that need to be performed. One is the configuration of the usage and health data collection. This can be done either using the Central Administration or PowerShell. This post focuses on how to do the configuration using powershell.


As the very first step we would need to bring up the SharePoint 2010 Management Shell.

Then, by issuing the cmdlet:




we can specify multiple parameters in order to set the data collection up:


  • -LoggingEnabled (1 or 0)
  • -UsageLogLocation (file path)
  • -UsageLogMaxSpaceGB [1-20]

More parameters exist, however: these are the most interesting ones. So, for example, issuing the following command:


Set-SPUsageService –LoggingEnabled 1 –UsageLogLocation C:\Logs -UsageLogMaxSpaceGB 3


would enable the usage data collection and write the corresponding logs to C:\Logs, up to amount of 3 GB. Please bear in mind that the logs max space must be within the interval [1-20].




There is also a way of specifying the usage data collection for a single event type, using the following cmdlet:



The parameters of interest are here:

  • -Identity <GUID>
  • -Enable
  • -DayRetained [1-30]

An example command would be like follows:


Set-SPUsageDefinition -Identity 0a79e3a1-c60d-473b-82b7-
f43c2b4da -Enable -DaysRetained 15


This would set the event type with the GUID to be kept in the logs for 15 days.


Until here, we could have done the same operations using the Central Administration. However, there is a configuration that can only be performed using PowerShell:


Usage Logging in a Different Database.


As we might have guessed, another cmdlet is needed for this operation:



It uses the following parameters of interest:

  • -DatabaseServer <Server>
  • -DatabaseName <DBName>
  • -DatabaseUsername <User>
  • -DatabasePassword <PWD>

The latter two parameters, –DatabaseUsername and –DatabasePassword, are only required if our DB user differs from the user we are currently logged on as.


What else there is to mention? Well, do test the above commands thoroughly before applying them in any productive environment. They affect the logging and hence may have a negative and severe impact if applied the wrong way (or just as they are –please DO NOT copy paste and execute them – the parameters need to be adapted to your needs).


For all three methods, there exists also an additional –Verbose parameter, that tells you about success or failure of the application.


Best regards & happy SP-configuring!


Read Full Post »