-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, null AS theAlias1, null AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

In my case the result of the query will be inserted in a temporary table in memory. The destination column for theAlias1 is of type INTEGER. When executing the query PostgreSQL gives me an error:

column "theAlias1" is of type integer but expression is of type text

So there is something wrong when the query is parsed, evaluated and executed.

Solving this was easy with the use of NULLIF. Zero equals zero so NULL is returned. Just as expected.

-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, NULLIF(0, 0) AS theAlias1, NULLIF(0, 0) AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

It seems this is a bug in the packages provided by Debian. After struggling for a while a simple

apt-get install libkrb53 --reinstall

fixed the problem and everything works again.

Enabling the “display-error” setting revealed that there was a database-problem (perhaps due to a crash of mysql).

#145 - Table './tl_search' is marked as crashed and should be repaired

The problem was that I have no shell-access to the server of the hosting provider and no administrative-console for the database. So I built a little “repair-script” to fix this issue.

// Typolight table repair script
define('TL_ROOT', dirname(__FILE__));
 
// Load the configuration
require_once('system/config/localconfig.php');
 
$con = mysql_connect($GLOBALS['TL_CONFIG']['dbHost'],
  $GLOBALS['TL_CONFIG']['dbUser'],
  $GLOBALS['TL_CONFIG']['dbPass']);
mysql_select_db($GLOBALS['TL_CONFIG']['dbDatabase'], $con);
 
// Repair table
$result = mysql_query("REPAIR TABLE tl_search", $con);
var_dump(mysql_fetch_array($result));
 
mysql_close($con);

Its placed where the “front-controller” (index.php) resides and after executing it via browser the problem is gone and the website is up and running again.

Value too long for type character varying(64)

Within a function (written with plpgsql) a dynamic query is built and executed via sql-EXECUTE. The error PostgreSQL gives me stated out that the error was in the line containing the EXECUTE-statement. But the query was of type TEXT so there is no length limitation.

Guide me

In the end it showed that the error PostgreSQL gave me was misleading. The final dynamic query itself was fine. So the sql-EXECUTE cannot be the cause of the error. 

The function returns a custom (composite) type (built via PostgreSQL CREATE TYPE). This custom type consists of a few “columns”. One of this column was indeed of type character varying(64) and was simply to short to hold the data collected inside the function.

Fixing the data type of that column in the custom composite type fixes the error.

The start is essential

I reconfigured everything, I checked the database-security, rebooted the virtual machine, re-created the content-sources. Nothing helped …

After some digging I found out that the start page of that site-collection (default.aspx) throws an exception due to a faulty web part…
This can’t be… Can it?! I removed the faulty web part from the default.aspx and the start page runs normal … and so does the crawler!

Because of an erroneous start page the whole crawling process for that site-collection is not working!

Conclusion

Make sure that the “entrance” to your site-collections is wide open and totally working …

PS: Excluding the default.aspx via “Crawl rules” does not work. The crawler still stops.

The error message was: Provisioning failed: File or arguments not valid for site template ‘OSRV’.

After consulting the logfiles I stated out that the cause of this problem was my own inattention. I  accidentally downloaded the Search Server 2008 in a language that was not installed on my system. So I also downloaded the language packs, too. But the error is still there. There is no way to delete the faulty SSP via the browser so the command-line is our friend.

stsadm -o deletessp -title SharedServices -deletedatabases -force

After running this command I was able to re-create the SSP via central administration. Everything works fine now …

Error

Clicking through the installation wizard went fine but then the installation cancelled with “nice” red error icons. A look into the logfile showed the following.

Property(S): ACTION = INSTALL
MSI (s) (08:D0) [23:01:25:354]: Note: 1: 1708
MSI (s) (08:D0) [23:01:25:354]: Produkt: MSXML 6.0 Parser (KB933579) -- Die Installation ist fehlgeschlagen.
 
MSI (s) (08:D0) [23:01:25:354]: Das Produkt wurde durch Windows Installer installiert. Produktname: MSXML 6.0 Parser (KB933579). Produktversion: 6.10.1200.0. Produktsprache: 1031. Erfolg- bzw. Fehlerstatus der Installation: 1603.
 
MSI (s) (08:D0) [23:01:25:385]: Cleaning up uninstalled install packages, if any exist

I downloaded the MSXML 6.0 Parser from the Microsoft Download page and tried to install it. Error! A newer product is already installed. A short look into “Software Installation” revealed that I have MSXML Parser 6.0 SP2 installed. Okay looks good for me but not for SQL Server 2008.

Being up-to-date is not always good

The installation routine depends on the installation of the MSXML Parser 6.0… In the end I uninstalled MSXML Parser 6.0 SP2 and started the installation again. Tadaaaa! It works. SQL Server was installed successfully. Now I can “re-apply” SP2 for the MSXML Parser 6.0

Woohoo

I started the windows command-line and entered date. It showed 2009-01-28. As you can see the year is 2009!
Having to do such steps to get an installation of SQL Server 2008 made me think I am in the year 1998! Wtf?!

Update: A friend of mine had problems with SQL Server 2008 installation, too.

Ausnahme bei der Execute-Methode der Auftragsdefinition 'Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition' (ID 92382b17-cf08-40f0-a2dc-0b7f97fa592f). Weitere Informationen werden unten angezeigt.
 
Die COM-Klassenfactory für die Komponente mit CLSID {629DA12E-9AD5-4FEC-B886-42C5982C5109} konnte aufgrund des folgenden Fehlers nicht abgerufen werden: 80070422.

This error-message was repeated every our. The Windows SharePoint Services Search Service was not functioning correctly. All permission were set correctly in the DCOM-config. Searching google brings am several posts and hints but none of them helped in my case.

Do not disable me, please!

Checking the Timer-Job-Status in central administration simply showed the job was not executed. The search-jobs from the Search Server were okay. So whats the matter? Everything worked before …
After looking inside the services-management for the server I was shocked! The Windows SharePoint Services Search had been deactivated! I don’t know why and how but after setting it to “auto” and starting the service everything runs well again.

Conclusion

Don’t assume anything! Always check the services-management of your service before assuming something else is wrong …

// Some static command here
$cmd = '/path/to/fop -c config.yml -fo input.fo -pdf outfile.pdf';
exec($cmd);

So quiet

This doesn’t work! There is no pdf-file. exec gives no output, no warning, no error … Simply nothing. If I run the command inside the shell the pdf files gets created as expected.

Use-Cache = true

The cause of the problem is the config-option use-cache which is set to true on default.
FOP wants to create a cache-file to speed up the font-embedding-process which fails in my case.
Running the fop-command as the user apache runs with gives an error. The creation of the cache-file fails due to missing filesystem permissions. I really have no idea why this output isn’t catched by exec. Some java-related behavior? Perhaps stdout is redirected somewhere else?

Use-Cache = false

I’m not using the “auto-detection”-feature for font-embedding as I clearly define where my fonts reside. So I added the option into my fop-config-file.

false

Finally everything works as expected.

Redirection

In order to get information of what fop does use the following command:

$ouput = array();
$ret = 0;
echo exec('/path/to/fop -fo test.fo -pdf test.pdf > /path/to/logfile.log 2>&1', $ouput, $ret);

Cannot complete this action. Please try again. at Microsoft.SharePoint.Library.SPRequestInternalClass.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd) 
   at Microsoft.SharePoint.Library.SPRequest.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)

Tell me

This is an error message every developer fells in love with. Its full of nothing…

Further analysis revealed that there must be a problem with a custom field definition inside that Content Type. Even more investigation found the culprit.

<Field Type="LookupMulti"
         DisplayName="CustomField"
         Required="FALSE"
         Description="My custom field"
         Group="Custom"
         StaticName="MyCustomField"
         Name="MyCustomField"
         ShowField="Title"
         ShowInDisplayForm="TRUE"
         ShowInEditForm="TRUE"
         ShowInNewForm="TRUE"
         ShowInViewForms="TRUE"
         Mult="TRUE"
         Sortable="FALSE"
         Indexed="TRUE"
         UnlimitedLengthInDocumentLibrary="TRUE"
         List="myList"
         SourceID="{31DCE571-D649-41b8-99D7-448F43FCEAC0}" />

Conclusion

NEVER set the attribute Indexed to TRUE when the field is a Lookup-Field that has the Mult-attribute set to TRUE!

<Field Type="LookupMulti"
         DisplayName="CustomField"
         Required="FALSE"
         Description="My custom field"
         Group="Custom"
         StaticName="MyCustomField"
         Name="MyCustomField"
         ShowField="Title"
         ShowInDisplayForm="TRUE"
         ShowInEditForm="TRUE"
         ShowInNewForm="TRUE"
         ShowInViewForms="TRUE"
         Mult="TRUE"
         Sortable="FALSE"
         Indexed="FALSE"
         UnlimitedLengthInDocumentLibrary="TRUE"
         List="myList"
         SourceID="{31DCE571-D649-41b8-99D7-448F43FCEAC0}"
/>