Common Table Expression for Database Structure

When copying data from one database to another, breaking constraints is always a problem. If you do not insert data in a certain sequence, you will get foreign key violations. So I tried to work out a CTE that starts with all tables that have no foreign keys, then the tables referencing them, then the once referencing them again, and so on… So came up with this:

WITH CTE (name,object_id, lvl)
AS
(
    select name, object_id, 0 AS lvl from sys.tables
    where object_id NOT IN (select parent_object_id from sys.foreign_keys)
   
UNION ALL

    select tbls.name, tbls.object_id , lvl + 1 from sys.tables tbls
    join sys.foreign_keys keys on tbls.object_id = keys.parent_object_id
    join CTE on CTE.object_id =  keys.referenced_object_id
)
SELECT * FROM CTE
OPTION (MAXRECURSION 10000)

Note that this will not work if you have self-referencing tables, ie. tables that have a foreign key pointing to its own primary key. Also the same tables may appear many times because they reference the same tables. And also if the same table have many foreign keys it will appear many times.

The conclusion is that this does not solve my problem, but it was fun to create the CTE anyway.

Experiences on upgrading EPiServer 4.51 to 4.62B part 2

Ok, so the upgrade has been done, but will the project compile?

Sadly the answer is no.

I got the exact same problems described here: http://world.episerver.com/templates/forum/pages/thread.aspx?id=19575&epslanguage=en. It took some time for me to understand the answer to the part they did give an answer to. They didn’t answer the second question at all.

Problem 1: WsrpHelper doesn’t exist any more

My solution, which saves me from having to go through 8-10 places and correct the code, was to create a new class inside the WsrpPortal.aspx.cs file:

class WsrpHelper
{
    public static IConsumerEnvironment ConsumerEnvironment
    {
        get { return ElektroPost.Wsrp.Consumer.ConsumerContext.ConsumerEnvironment; }
        set { ElektroPost.Wsrp.Consumer.ConsumerContext.ConsumerEnvironment = value; }
    }

    public static void EnsureConsumerEnvironment()
    {
        if (ElektroPost.Wsrp.Consumer.ConsumerContext.ConsumerEnvironment == null)
        {
            ElektroPost.Wsrp.Consumer.ConsumerContext.ConsumerEnvironment = ConsumerFactory.ConsumerEnvironmentInstance();
        }
    }
}

Problem 2: LanguageManager.GetContextLanguage() is obsolete

It says in the error message that you should use LanguageContext.Current as a replacement, but that would create a type conversion exception.

I am guessing that you can to use LanguageContext.Current.CurrentUILanguageID as a replacement for GetContextLanguage() (please do correct me if I’m wrong).

DISCLAIMER:
I haven’t been able to test my solution, since the webs I am working on don’t actually use the portal framework. My code compiles now, so the web is up and running, and I am happy for the time being. If anyone finds any flaw in my solutions please don’t hesistate to leave a comment.

The EPiServer Offline Package is a ZIP-file

So if you for instance need to just upgrade the database, not the whole EPiServer installation, you can just rename the offline upgrade package from .pkg to .zip, and you will find all the files used by the upgrade wizard inside.

Ypou can create an offline upgrade package from and to the versions you want using the EPiServer Manager, as mentioned in my previous post.

The database scripts are located in the “Upgrade” folder, and if you sort them ascending by name and run them in that order, you should be able to upgrade the database “manually”.

Scenarios where this method may be used may be

• you did/tested the upgrade in your development environment and then deployed the upgraded files
• you have already upgraded EPiServer on a staging server and the production database (which is an earlier version) should be restored on the staging server

The EPiServer Manager does other things than just copying files, like registering components in the GAC, so use the EPiServer Manager whenever possible. Also, remember to always have nescessary backups available.

Experiences from upgrading EPiServer from version 4.51 to 4.62B

Ok, so previously I have upgraded my project files and solutions from Visual Studio 2003 to 2008, and have upgraded to master pages. I wrote about this in an earlier post: http://stgaup.blogspot.com/2010/02/upgrading-episerver-to-masterpages.html.

So now the next step. Upgrading the EPiServer version from 4.51 to 4.62B.

Since I am going to upgrade at least 2 sites, and someone in IT Operations needs to do the same upgrade on the production systems, I thought it would be a good idea to create an offline install. I had to google a bit and eventually fond out that to create an offline package, you need to:

1. Start EPiServer Manager
2. On the Tools menu, select “Create offline installation…”
3. Click Next
4. Select “Upgrade”
5. Select From version in my case 4.51)
6. Select To Version (4.62B)
7. Specify directory where the package should be created.
8. Click “Create”.

I had no problems with this part of the job.

Next I had to do the upgrade:

1. Backup all files and the EPiServer database.
2. Right-click the web site to upgrade in the EPiServer Manager, and select “Upgrade…”.
3. Click Next.
4. Select “Offline” and then browse to the package created before.
5. Click Next.
6. Review upgrade info, then click “Upgrade”.

The next thing happening was that the upgrade was being done, and the progress bar was showing some progress, until about 20% on the way. Then I got an error message: “Failed to register ASP.NET client scripts on this site”

It turns out that the EPiServer Manager is not able to install when there are versions of the .NET Framework installed after version 2.0. So the dirty trick you need to do is to remove the 3.0 and 3.5 folders from the WINDOWS\Microsoft .NET\Framework folder because EPiServer Manager will try to locate aspnet_regiis.exe (and maybe other command line utilities) in those folders, and it’s not there. This thread was helpful: http://world.episerver.com/Templates/Forum/Pages/Thread.aspx?id=17376&epslanguage=en.

Ok, so after I had moved those folders, it seemed that the upgrade worked, until I tried to browse the web:

EPiServer 4.62.0.533 can only be used with database version 100, current version is 90. Make sure both database and assemblies are upgraded correctly.

I didn’t get any errors while upgrading. Everything seemed to go well, but it didn’t. The EPiServer Manager failed to upgrade the database.

I am assuming at this point that the database upgrade failed because the web was using Windows Integrated security with SQL Server. I thought it could work because I had made sure that my windows user account had owner rights to the database, but sadly it failed.

Tip: Don’t use Windows Integrated Security with EPiServer (when upgrading) even though Microsoft recommends that as the most secure way of accessing SQL Server. If you do, you will (probably) need to set up your site with impersonation, and turn off anonymous access.

Ok, so then I tried to run the upgrade once more after setting a SQL Server username/password. I then got the message:

The site is already up to date (4.62.0.533) – no new versions available.

So now time for my next dirty trick, one that I have used before, which is to copy the old EPiServer.dll back into the bin folder of the web site. (Of course I had a backup.)

So new upgrade attempt. First had to restart the EPiServer Manager, because it still thoght the web was version 4.62B. After restarting it said 4.51, as I intended it to.

This time the upgrade worked as it should, and the web is up and runnig again, now og EPiServer 4.62B.

IMPORTANT: Copy back the .NET 3.0 and 3.5 Framwork files to their correct location!

NEXT STEP: Upgrade to CMS 5? Am I brave enough?

My Second SmallBasic program

This one draws a sinus curve (well a cosinus curve):

GraphicsWindow.Title = "Hello World!"
GraphicsWindow.BackgroundColor = "Yellow"
GraphicsWindow.Width = 320
GraphicsWindow.Height = 200
GraphicsWindow.Show()

oldx = 0
oldy = Math.Cos(0) * 100 + 100

For x = 1 To 320
  y = Math.Cos(x/10) * 100 + 100
  GraphicsWindow.DrawLine(oldx,oldy,x,y)
  oldx = x
  oldy = y
EndFor

My first SmallBasic program

Ok, my first was “Hello World”, but this is my first using the GraphicsWindow:

GraphicsWindow.Title = "Hello World!"
GraphicsWindow.BackgroundColor = "Yellow"
GraphicsWindow.Width = 320
GraphicsWindow.Height = 200
GraphicsWindow.Show()

oldx = Math.Sin(0) * 100 + 160
oldy = Math.Cos(0) * 100 + 100

For i = 0.1 To 2 * Math.Pi Step 0.1
  x = Math.Sin(i) * 100 + 160
  y = Math.Cos(i) * 100 + 100
  GraphicsWindow.DrawLine(oldx,oldy,x,y)
  oldx = x
  oldy = y
EndFor

What does it do? It draws a circle. Great huh? Oh I could have used GraphicsWindow.DrawCircle? Amazing stuff :P

Btw SmallBasic may be downloaded from http://msdn.microsoft.com/en-us/devlabs/cc950524.aspx.

Upgrading EPiServer to MasterPages

Initial Status:
I have already upgraded the EPiServer solution from Visual Studio 2003 / .NET 1.1 to Visual Studio 2008 / .NET 2.0/3.5. First upgraded to VS2005/.NET 2.0 by opening the projects in VS2005 and using the wizard, then converting the project to a web application. Then did the same again, opening the project in VS 2008. Everything seemed to work fine after the upgrade. So next step is to upgrade from using EPiServer:DefaultFramework to using master pages.

Next steps:
I found the (very good I might add) article: http://world.episerver.com/Articles/Items/Experiences-from-migrating-to-EPiServer-461-and-ASPNET-20/ and tried to follow the steps described from the section called “Upgrading your custom templates to ASP.NET 2.0”. However there seems to be some little information missing:

1. In addition to changing the <@ Control … to <@ Master … you must also in code-behind change the inheritance so that the master page inherits from System.Web.UI.MasterPage in stead of EPiServer.WebControls.ContentFramework.
   This will cause some problems:
1. If you have any references to CurrentPage, you will need to fix it. I fixed it by creating a new property on the master page called CurrentPage:
   
   public PageData CurrentPage
   {
       get
       {
           PageBase pb = (PageBase)this.Page;
           return pb.CurrentPage;
       }
   }
   
   
2. Also if you are using any commands that are not prefixed and are using functionality from the previous base class you will need to fix them:
1. Translate(…) => EPiServer.Global.EPLang.Translate(…)
   I solved this by creating a private function in the master page code-behind, which saved me from changing code in multiple places:

private string Translate(string key)
{
    return EPiServer.Global.EPLang.Translate(key);
}


2. GetPage(…) => EPiServer.Global.EPDataFactory.GetPage(…)
   Again I solved it by creating a private function with the same name:

private PageData GetPage(PageReference pageLink)
{
    return EPiServer.Global.EPDataFactory.GetPage(pageLink);
}



2. The process of converting from the 1.1 style of declaring the controls in code-behind to the 2.0 way using the .designer.cs file is not always working as is should. I had to go into the code-behind file and remove declarations of controls, and then made a slight change to the front master page file, and the saved it, so that the controls using the runat=”server” attribute were (automatically) declared in the designer.cs file. Also some events vere explicitly declared in code-behind (opposed to the new way of using “AutoEventWireup=True”. I just removed them as they were doing nothing anyway.
   
   
3. Also had a small problem due to some additions to the asp.net control gallery and poor naming conventions. The old EPiServer Content Framework files declared a conrtol called simply “Menu”. This name crashes with the “System.Web.UI.WebControls.Menu” web control, so I just changed the name.
   

And now my web is up and running with EPiServer 4.51 (on VS2008) and using Master Pages (on only one page so far: default.aspx). After changing all aspx-web forms so that they use the new master page, the next step will be to upgrade EPiServer to 4.62B, and thanks to the previously linked article this should hopefully be a piece of cake.