Archive for December, 2007

MSSQL Unicode Errors on PHP

Friday, December 21st, 2007

If you get the error:

Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier.

One of the errors, could be infact that the connector can’t understand some data types in the MSSQL table. These are generally:

sysname, uniqueidentifier, ntext and nvarchar.

The easiest way to fix that, is to select with a conversion in place straight away. For example, using the CAST function in mssql, we are able to extract sysname as a varchar:

SELECT CAST(job_id AS VARCHAR(255)) as element_name) FROM [dbo].[....]

You can cast any element as any other element. Just remember to not cast as something PHP doesn’t support!

MSSQL Sysjobs_Schedules table

Monday, December 17th, 2007

There are a number of fields in the sysjobs_schedules table that are confusing and not documented very well. One of those fields is the freq_interval when dealing with weekly/monthly schedules.

Very quickly (and I will detail a bit more later in another post) the freq_interval column when posting a ‘weekly’ job, to run on specified days, will add the day values of the numbers together;

The numbers are:

1 Sunday
2 Monday
4 Tuesday
8 Wednesday
16 Thursday
32 Friday
64 Saturday

So if you have a job that runs mon-fri, the value of the field will be 62. That’s 2+4+8+16+32 = 62.

Enjoy.

PHP5 Auto Installer on Windows XP

Wednesday, December 12th, 2007

If you have to use the auto-installer, just remember, the /ext directory does not get included in the package. You have to download the Windows ZIP package, which contains the EXT directory. Extract the contents to c:\php5\ for a quick and fuss free install.

Otherwise, also remember, the extensions directive in the php.ini also needs to be updated to reflect this accordingly.

404 Headers and Images!

Tuesday, December 11th, 2007

For dynamic systems sometimes we rely on the use of a 404 redirect to manage exceptions. The problem with this is that sometimes we are caught between a rock and a hard place. The rock, is the browser receiving the 404 header before we have a chance to tell it that it’s not actually a 404.

Take this example of a 404 apache redirect:

header(”HTTP/1.0 200 OK”);
echo “I like cheese and I like cake.”;

What’s the problem? Nothing at this point and this is because browsers are able to quickly read and understand the new header before it pushes out the content to the browser window. It’s the same when you deal with streaming images too, you can:

header(”HTTP/1.0 200 OK”);
header(”content-type: image/png”);
print_r(file_get_contents(’my.png’));

This will work okay too, but what about when your dealing with cookies? It’s hard enough for a browser to set/forget cookies when you tell it too, but some browsers are definately not happy when you try and set a cookie on an image - I guess in their defense, who needs a cookie for an image? Well, we do!

A quick way around this, is to use mod_rewrite, within apache instead. This will then allow you to get a 200 OK by default, so your not confusing the situation when you send in multiple headers and then a cookie all in one transaction. That way, some of the less-coder-friendly browsers will be able to pick it up in a snap.

As soon as we work out exactly why - we will let you know!