Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

  • Brian Smith's Microsoft Project Support Blog

    How to check a project in through the database

    • 35 Comments

    OK, so that was a mean trick.  Using a title like that to get you and your search engine to read about why you shouldn't check a project in through the database.  In the words of Douglas Adams "It doesn't necessarily get you where you wanted to go, but it turns out to be where you needed to be."

    With each successive version of Project Server we try to discourage direct database access more and more - and with 2007 we don't even document the ones we want you to stay away from.  There may be times when you do need to get to these databases to read stuff if it isn't available through the PSI or reporting database - and some very rare cases where bugs may lead to some database update being needed to resolve some data issue.  But in almost all cases a checked out project can be checked in without resorting to SQL.  The following steps are similar to how you would troubleshoot other queue problems - but are presented here specifically to work with checked out projects.

    1. The best first step if a project that you have closed and checked in says it is still checked out is to open read-only, then close - and then leave a short while and try and re-open.  This should flush through any pending check-in that gets caused by the closing bug in Project Professional 2007.  As mentioned before - if it is a large project or your server is VERY busy the save can take a little while - so patience may also be required.

    2. Assuming step 1 didn't help then time to look at the queue.  First we need to confirm it is still working.  A couple of options here - first in Manage Queue add the Job Completion State of "Success" to the view.  This should then show you what has been working.  A successful job in the recent past - or a job that says "Processing" and the % complete is still increasing are a good indication that things are working (just not for you).  A second check if this doesn't make things clear is to look at Task Manager on the Application Server (Right click the task bar and select Task Manager is a quick way to get this running) and check that you see multiple instances of Microsoft.Office.Project.Server.Queuing.exe on the Processes tab.  There should be (Number of Shared Services Providers with provisioned PWA site) + 1 instances.  So in most cases 2 - but possibly more.  Just seeing 1 is an indication that when the service started the database was inaccessible to the service so it could start the SSP specific instances.  Re-starting the service should resolve this.  just because in Administrative Tools, Services it says "Started" next to the service does not mean it is working!

    3. So we know the queue is working and I am guessing at this point that you have a "Waiting to be processed" against a Project check-in job.  And you may have selected a "Force check-in" several times too.  The word "Force" here is a misnomer - and should really be worded "Please check-in when you are ready".  If the job is waiting then it is waiting for something, and no amount of reboots, queue stop/starts will shift it.  We need to look deeper to find out what's holding things up.  In Manage Queue set the Job History to go back far enough to see any activity for the problem project, set the Filter Type to By Project and then just select the project you are interested in.  This should then show your pending check-in job as well as what is blocking it.

    image

    4. So now you should see what is blocking the check-in, and the owner will show who was the last person doing something.  In my case it was a save from Project Professional that hadn't complete (still "getting queued" - which means data is coming from the client cache to the message queue). 

    5. If you are not the owner of the blocking job then get that person to repeat step 1.  This should allow the job to complete; although in the queue it may show as a cancel and re-save.  In this case the cancellation is done by the server as the save was in the very early stage.  If this worked then all is now well and you can get at the project.  This is the best resolution because NO DATA IS LOST!

    6. If you can't find the owner, or they have since deleted their local cache then step 5 will not be possible and the only option then is to cancel the job (after also checking the Advanced Option, Cancel jobs getting enqueued and optionally un-checking Cancel subsequent jobs in the correlation.)  Once the job is canceled then any subsequent jobs should complete OK and you are back in business.  Any changes made by the user who was saving WILL BE LOST!

    And if this doesn't work for you and you really do need to check-in through the database - let me know!

    Technorati Tags: Project Server 2007

  • Brian Smith's Microsoft Project Support Blog

    A couple more cube build error messages you might come across.

    • 8 Comments

    A couple more cube build error messages I have seen recently.  The first is related to a time out with Analysis Services 2005 and the clue is that failure will be just over an hour into the build (assuming the timeout is still the default 3600 seconds).  The error is:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to process the Analysis Services database <cube name> on the <Analysis Server name>  server. Error: Internal error: The operation terminated unsuccessfully
    • Internal error: The operation terminated unsuccessfully. Internal error: The operation terminated unsuccessfully. OLE DB error: OLE DB or ODBC error: Unspecified error. Errors in the OLAP storage engine: An error occurred while processing the 'Assignment Timephased' partition of the 'Assignment Timephased' measure group for the 'Assignment Timephased' cube from the <cube name>  database.

    The first part of the error message will be localized if you are using a MUI - the second will not.

    To resolve the issue set the advanced property ExternalCommandTimeout to a value that will allow the building of the cube.  The default is 3600 (seconds) which is one hour.  Increasing to 36000 will be ten hours.  The value could be increased further or reduced depending if the cube builds within this modified time.

    To change the value of the timeout property go to Management Studio for SQL Server 2005 and connect to Analysis Services.  Right click the server name in the left pane and select Properties.  Check the option to Show Advanced (All) Properties then scroll down to ExternalCommandTimeout.  Change the value in the Value column then click OK.  A restart is not required.

    Another workaround would be to reduce the complexity of the cube build by either limiting dates or removing some or all added dimensions.  This workaround is unlikely to be a workable answer for most customers.

    The fact that a restart of the service is not required leads me to the second error message, which can appear if you do restart and then immediately try another cube build:-

    • Failed to build the OLAP cubes. Error: Analysis Services session failed with the following error: Failed to connect to the Analysis Services server <Analysis Server name>. Error: File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\DBCUbe260.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the '<random cube name>' database cryptography key. One possible reason for this error is that the service account has changed. File system error: Error opening file; \\?\C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\FarmPWA.0.db\0.CryptKey.bin is not a disk file or file is not accessible. Errors in the metadata manager. Processing for the database will be disabled because an error occurred while loading the 'FarmPWA' database cryptography key. One possible reason for this error is that the service account has changed.

    There may well be other scenarios that give the same error, but for the scenario where you have just restarted the server then just try the build again and all will work. 

    Technorati Tags: Project Server 2007

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: An unknown error in Project Center, usually related to filters and duplicate custom field values

    • 29 Comments

    The fix for this frequently hit bug was released KB 2598251, and now the KB article at http://support.microsoft.com/kb/2598251 has been updated to include the SQL scripts that will clean up the duplicate values that lead to the error.  These scripts will correct the data, and the fix will stop the condition returning.  The fix itself has a version number of 14.0.6117.5002 – and if you load the February CU rollup package with this same version number then you will also get the fix.  The single Project Server package has been updated to point to the 2598251 patch – as this includes the fix, but also includes the February cumulative update.

    So to summarize:

    And finally – to help the search engines find this posting, the ULS logs will indicate an exception error similar to the following:

    Exception occurred in method Microsoft.Office.Project.Server.BusinessLayer.Project.ProjectGetProjectCenterProjectsForGridJson Microsoft.Office.Project.Server.DataAccessLayer.FilterDal+FilterException: Error during filter query execution. Query: declare @ResUid UniqueIdentifier; set @ResUid = ff02387a-234e-4323-9e33-dbbf6f11880e; declare @PermUid UniqueIdentifier; set @PermUid = a120a079-75bc-4f0f-b376-3fb0ae9ac940; declare @ViewUid UniqueIdentifier; set @ViewUid = 63d3499e-df27-401c-af58-ebb9607beae8; declare @P0 UniqueIdentifier; set @P0 = 2d9ba6f2-d3d4-47f1-8661-5af3d695f8ed; declare @P1 UniqueIdentifier; set @P1 = 0ad53bb6-15ee-476a-ab05-7bb434b50466; SET NOCOUNT ON SELECT T.PROJ_UID INTO #T0 FROM dbo.MSP_PROJECTS AS P INNER JOIN dbo.MSP_TASKS AS T ON T.PROJ_UID = P.PROJ_UID INNER JOIN dbo.MSP_RESOURCES AS R ON R.RES_UID = P.WRES_UID LEFT JOIN dbo.MSP_WORKFLOW_STATUS AS WFSTS ON WFSTS.PROJ_UID = P.PROJ_UID INNER JOIN dbo.MSP_WEB_FN_SEC_GetAllProjectsResCanViewByViewID(@ResUid, @PermUid, @ViewUid, 3) AS perm ON perm.PROJ_UID = T.PROJ_UID LEFT JOIN dbo.ProjectSummaryCustomFields AS TABLEALIAS_0 ON TABLEALIAS_0.PROJ_UID = P.PROJ_UID AND TABLEALIAS_0.MD_PROP_UID = @P0 WHERE T.TASK_OPTINDX = 1.0 AND (ISNULL(WFSTS.STAGE_STATUS,-1) IN (-1, 1,2,3,5,6)) AND ((TABLEALIAS_0.CODE_VALUE <> @P1) OR (TABLEALIAS_0.CODE_VALUE IS NULL)) CREATE CLUSTERED INDEX PK_#T0 ON #T0 (PROJ_UID) SET NOCOUNT OFF SELECT T.PROJ_UID , P.PROJ_NAME , T.TASK_START_DATE , T.TASK_FINISH_DATE , T.TASK_PCT_COMP , T.TASK_WORK , T.TASK_DUR , R.RES_NAME , P.WPROJ_LAST_PUB , P.PROJ_OPT_MINUTES_PER_DAY , P.PROJ_OPT_MINUTES_PER_WEEK , P.PROJ_OPT_DAYS_PER_MONTH , T.TASK_SUMMARY_PROGRESS_DATE , T.TASK_IS_MILESTONE , dbo.MSP_FN_HYPERLINK_HREF(T.TASK_HYPERLINK_ADDRESS, T.TASK_HYPERLINK_SUB_ADDRESS) AS TASK_HYPERLINK_HREF , T.TASK_OUTLINE_LEVEL , P.PROJ_TYPE , T.TASK_DUR_FMT , P.WSTS_SERVER_UID , P.PROJ_OPT_CURRENCY_CODE , P.PROJ_ACTIVE_RISK_COUNT , P.PROJ_ACTIVE_ISSUE_COUNT , P.PROJ_TOTAL_DOC_COUNT , WOB.WOBJ_ISSUE_REF_CNT , WOB.WOBJ_RISK_REF_CNT , WOB.WOBJ_DOC_REF_CNT , PJSYNC.SYNC_WSS_LIST_UID , T.TASK_COMPLETE_THROUGH , (CASE WHEN T.TASK_UID=T.TASK_PARENT_UID THEN 1 ELSE 0 END) AS TASK_IS_PROJECT_SUMMARY FROM dbo.MSP_PROJECTS AS P INNER JOIN dbo.MSP_TASKS AS T ON T.PROJ_UID = P.PROJ_UID INNER JOIN dbo.MSP_RESOURCES AS R ON R.RES_UID = P.WRES_UID LEFT JOIN dbo.MSP_WORKFLOW_STATUS AS WFSTS ON WFSTS.PROJ_UID = P.PROJ_UID INNER JOIN #T0 AS keys ON keys.PROJ_UID = P.PROJ_UID LEFT JOIN (SELECT WOBJ_PROJ_UID as PROJ_UID,[4] as WOBJ_ISSUE_REF_CNT, [5] as WOBJ_RISK_REF_CNT, [3] as WOBJ_DOC_REF_CNT FROM ( SELECT WOBJ_TYPE, WOBJ_PROJ_UID FROM MSP_WEB_OBJECTS WHERE WOBJ_TASK_UID='00000000-0000-0000-0000-000000000000') pwob PIVOT (COUNT(WOBJ_TYPE) FOR WOBJ_TYPE in([3] ,[4],[5])) AS pvt) AS WOB ON WOB.PROJ_UID = P.PROJ_UID LEFT JOIN dbo.MSP_SYNC_PROJECT_SETTINGS AS PJSYNC ON PJSYNC.PROJ_UID = P.PROJ_UID WHERE T.TASK_OPTINDX = 1.0 AND (ISNULL(WFSTS.STAGE_STATUS,-1) IN (-1, 1,2,3,5,6)) DROP TABLE #T0; --->

    System.Data.ConstraintException: Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints.

    at System.Data.DataSet.EnableConstraints()
    at System.Data.DataSet.set_EnforceConstraints(Boolean value)
    at Microsoft.Office.Project.Server.DataAccessLayer.DAL.SubDal.FillTypedDataSet(Boolean allowCache, DataSet typedDataSet, String[] tables, SqlCommand sqlCommand, Boolean enforceConstraints)
    at Microsoft.Office.Project.Server.DataAccessLayer.DAL.SubDal.FillTypedDataSet(DataSet typedDataSet, String[] tables, SqlCommand sqlCommand, Boolean enforceConstraints)
    at Microsoft.Office.Project.Server.DataAccessLayer.FilterDal.FillDataSet(QueryState queryState)
    --- End of inner exception stack trace ---
    at Microsoft.Office.Project.Server.DataAccessLayer.FilterDal.FillDataSet(QueryState queryState)
    at Microsoft.Office.Project.Server.Utility.FilterDalQueryInfo.Query()
    at Microsoft.Office.Project.Server.BusinessLayer.Project.ProjectQueryInfo.Query()
    at Microsoft.Office.Project.Server.BusinessLayer.Project.ProjectCenterQueryInfo.Query()
    at Microsoft.Office.Project.Server.Utility.JsGridPopulationManager.InitializeSerializer(TableQueryInfo tableInfo, OrderInfo orderInfo, SliceInfo sliceInfo, Guid groupSchemeUid, Nullable`1 ganttSchemeUid, Boolean serializeStyles, Func`1 getChanges, Boolean serializeUnfilteredHierarchy, Boolean serializeLookupTableInfo, Boolean showTimeWithDates, String rowFilter)
    at Microsoft.Office.Project.Server.Utility.JsGridPopulationManager.InitializeSerializer(TableQueryInfo tableInfo, ViewPropertyGroup properties, JsGridSerializerArguments gridSerializerArgs, Func`1 getChanges)
    at Microsoft.Office.Project.Server.BusinessLayer.Project.GetProjectCenterProjectsForGridJson(JsGridSerializerArguments gridSerializerArgs, Guid viewUid, Int32 store, Boolean showInsertedProjects, Boolean clearPersistedProperties)
    at Microsoft.Office.Project.Server.Wcf.Implementation.PWAImpl.ProjectGetProjectCenterProjectsForGridJson(JsGridSerializerArguments gridSerializerArgs, Guid viewUid, Int32 store, Boolean showInsertedProjects, Boolean clearPersistedProperties)

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2007: Check-in still pending?

    • 36 Comments

    ***UPDATE***  Please see my posting on the December 2008 CU - http://blogs.msdn.com/brismith/archive/2008/12/17/project-server-2007-december-2008-cumulative-update-released.aspx.  The Project Professional 2007 CU - http://support.microsoft.com/kb/959643 has a fix for this issue!

    *** 2nd Update *** But also see http://blogs.msdn.com/brismith/archive/2009/02/11/project-server-2007-check-in-still-pending-even-after-december-cu.aspx 

    I replied to a comment on this topic – but think it warrants a new posting so I have polished my reply and added some stuff.  I am aware customers are still having some issues with check-in pending and I think it may be a timing issue around closing and opening Project.  I haven’t been able to repro this so would love to hear some consistent repro steps based on the August Cumulative Update – if anyone out there can make it happen to order.

    However, I have some ideas what might lead to the issue.  When you close Project we now give a message to ensure any saves that are in progress get a chance to complete.  However this only waits for the save from client to the queue to complete - then the "real" save from the queue to the database happens - then any publish and check-in jobs.  So the client may be closed when the check-in completes and so doesn't get the message – and will still think the check-in is pending.  On opening it takes a little while for the communication to the server and the responses for any updates on pending check-ins etc – and you may see a message Offline changes - and if the user does a File, Open immediately then they may see Check-in pending for a project that is really checked in.  This will not get updated while the dialog is open.  Either closing the dialog and re-opening - or opening a "pending" project (read only) and then closing should flush things through and get the project available. This is by far the best approach rather than clearing the cache as it does not risk any data loss.  The above symptoms may never appear on a very fast network, and may appear more often in a WAN situation where there is high latency between the client and server.

    But as I say, I haven’t been able to repro, even from home, where I have to traverse my home wireless network, then another wireless link a few miles across the valley before getting on to a T1 link and the internet.  Another few hops and I get to my server.  The ping time is a pretty respectable 50ms across 9 hops.  Just to add a little load to my server I set all my projects publishing from ProjTool too – but I never see check-in pending.  Perhaps I need to be saving a much larger project and have lots of custom fields at the task level?  So for any repro I’d also like to know project size, custom fields, network parameters such as a ping and tracert to the server.

    Technorati Tags:
  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Common Project Web App (PWA) Provisioning Problems

    • 6 Comments

    This post rounds up a few of the more common issues that customers run into – either when provisioning a new Project Server 2010 Project Web App (PWA) site – or more commonly when provisioning a site against a set of existing databases (either 2007 or 2010 databases).  As you should know by now Project Server 2010 supports provisioning against a full set of 5 existing databases – the usual 4 project ones (Archive, Draft, Published and Reporting) and also the Content DB that contains a the PWA site you want to provision against.  The first thing to remember is that you cannot restore a Content DB to the same farm to make a copy of a PWA site – even on a different port.  You will get an error like this, and following the workaround in the message will not help you create a duplicate:

    The attach operation cannot continue because another object in this farm already contains the same ID. Each object in a farm must have a unique ID. In order to proceed with the attach operation you must assign a new ID to this database. To attach this database with a new ID, use the Mount-SPContentDatabase command with the -AssignNewDatabaseId parameter. Note that if this new database and an existing database contain the same site collections, attaching this database will likely result in orphaned site collections due to conflicts between the two databases.

    So not directly a provisioning problem – but one error you may run in to if you try to duplicate a PWA instance within the same farm.

    The next group of scenarios will generate the same error – and I’ll list the various reasons this error may appear.  In this scenario I am restoring and provisioning against a set of databases from another server.  The first thing you will see is “Failed – see the Application event Log” and when you open this you will see a series of errors, the first being the generic Event ID 7070 (Source: Project Server, Task Category: Provisioning)

    Provisioning 'PWA': One or more of the databases already contains schema. When editing or creating a Project Server instance, you may specify:
    * Four databases that do not exist
    * Four existing, blank databases
    * Four existing Project Server databases of the same version from the same installation.
    Combinations of blank, new, and existing databases are not allowed.

    Followed by Event ID 6993

    Provisioning 'PWA': Failed to provision databases. An exception occurred: Provisioning failed because the databases specified did not match.

    then Event ID 6958

    Provisioning 'PWA': Database provisioning failed.

    and finally Event ID 6971

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Provisioning failed because the databases specified did not match.
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       --- End of inner exception stack trace ---
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    You will see exactly the same errors in the ULS logs – and the more useful information level log EventID 6975, which will read something like this – although yours will likely vary depending on the reason for your failure (I know why mine failed already, because I broke it on purpose).  I have also put in some line breaks to make it more readable for each of the databases.

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = NotCreated
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    It then becomes obvious that my Published is the one that is different – and if I go back and check what happened I will discover that when I restored my Published database I accidentally named it Prj_Published and not the Proj_Published that I entered on the PWA provisioning page.  Just re-name the DB and try again and all will be well. The type could happen either when restoring or when provisioning – but will give a similar error.  A slight variation on this theme is if the database you type exists but is just empty (you haven’t restored anything yet) – and you will see a state of Empty.

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = Empty
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    The other thing that is checked when restoring is that the databases actually are a “matching set” and this is done in a couple of ways.  There are a couple of extended properties defined on the Project Server databases (you may also have your own defined for various purposes) and the first of these is the ProjectCollectionGuid – and this should match for all of the 4 project databases.  If for some reason this does not match then the failure will be similar to the ones above – the same event log entries in terms of EventID, and this time the ULS log EventID 6975 looks OK:

    Provisioning 'PWA': Databases specified for site 'ProjectServer' are as follows:

    • Published: Name = 'Proj_Published', State = ProjectSchema
    • Draft: Name = 'Proj_Draft', State = ProjectSchema
    • Archive: Name = 'Proj_Archive', State = ProjectSchema
    • Reporting: Name = 'Proj_Reporting', State = ProjectSchema

    but looking closer at the Application event Log Event ID 6971 (or the ULS log version) will show a slightly different error:

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Mismatched databases.   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)     -
    -- End of inner exception stack trace ---   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)   
    at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    So Mismatched databases, rather than Provisioning failed because the databases specified did not match – very similar meaning, but different root cause and different type of mismatch.  The solution here is to ensure that your set of databases came from the same set – you cannot expect things to work if you mix things up with databases from different PWA instances. 

    The only exception I would make here is a trick we sometimes use in support to avoid having to get customers to send us all 4 databases if our repro of their issue does not require the Archive or Reporting databases. You can fool Project Server into provisioning with an ‘empty’ archive and reporting database, as long as it isn’t really empty – but just has schema (all the tables, views etc.) created in the same version of Project Server (usually by just provisioning a new site and backing up and then restoring the archive and reporting db).  In this scenario you would copy the ProjectCollectionGuid from the draft or published to the archive and reporting – to ensure they all matched.  Not something you would do in production – as you would lose reporting data (and yiur archive) – but might make sense for some transfers to a development system for example.

    The final mismatch that can occur and can be more difficult to spot the problem – is if you accidentally restore your databases to the wrong type – and to simulate this error I restored my Draft database but accidentally chose the backup of my Published database to restore it from.  The Event log errors are the same as the original ones – and the information message from the ULS EventID 6975 looks like the ‘typo’ problem – but the secret to the failure is in the other Extended Property – the ProjectDatabaseType.  In this case my extended properties look like this:

    image

    And the name of the database is typed correctly – but the ProjectDatabaseType should be ‘Working’, but instead says ‘Published’.  So Draft has a Type of ‘Working’ - Archive has a type of ‘Versions’ – Published and Reporting use the same terms.  Obviously the only way to resolve this is to restore the correct databases.  Just changing this value will likely lead to very bad things…

    Moving on from mismatch issues, here are a couple of issues that you might see once Language Packs come in to play (and I’m not specifically going in to different SQL Collation issues – but they can give problems too – perhaps another post for this next time I have a good repro to document).

    I’ll document the errors first, and then give details of the cause:

    The first error from the Application event log – Event ID 7110

    Failed to connect Proj_Published to PWA because the language of the database (English) does not match the language of the site (Portuguese - Brazilian).

    followed by the 6993 and 6958 errors we have already seen, and then the 6971, but again with a slight variation on the text.

    Failed to provision site PWA with error: Microsoft.Office.Project.Server.Administration.ProvisionException: Failed to provision databases. ---> Microsoft.Office.Project.Server.Administration.ProvisionException: Language of database does not match language of site
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CheckMatchingLcid(Int32 lcid, String connectionString, String siteName)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       --- End of inner exception stack trace ---
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.EnsureDatabases(ProjectProvisionSettings provset, SPSite pwaSite, String adminName, String adminEmail, ProjectDatabaseStateType& originalDatabaseState, Guid& adminGuid)
       at Microsoft.Office.Project.Server.Administration.PsiServiceApplication.CreateSite(ProjectProvisionSettings provset)

    In this case I took a backup from an en-US site, and tried to provision on my en-US server with the language setting changed to pt-Br.  So even if you have the language pack installed (en-US in this case) you cannot change the base language of a provisioned set of databases – you must provision in the same language.

    One slight variation on this theme and switching to a Project Server 2007 scenario  – which had me confused for a while, was the following scenario.  I was sure the site was US English – so tried to provision and got this error (Event ID 7110)

    Failed to connect Proj_Published to PWA because the language of the database (Portuguese - Brazilian) does not match the language of the site (English).

    OK, lets try that with pt-Br selected – hmm – Catch-22…

    Failed to connect Proj_Draft to PWA because the language of the database (English) does not match the language of the site (Portuguese - Brazilian).

    I have changed the nationality of this customer – to protect their identity – but they had been using an undocumented, unsupported workaround to get notification e-mails in a different language than the base – by updating the WADMIN_DEFAULT_LANGUAGE setting.  In 2007 this existed in both the Draft and Published databases – and if the two didn’t agree you would get this bizarre situation when it wouldn’t provision in either language.  In 2010 we only have that table in the Published database – so only see the first occurrence of this error.  If you tried to provision in the ‘other’ language then it would work – and your site would be provisioned be in that other language – but I think I’d have to say this isn’t supported as I am certain this wasn’t a tested scenario…

Page 5 of 98 (487 items) «34567»