Blog Archives

No tuples available at this result index in […]

Recently I was creating a simple PHP webpage that required an MSSQL connection for a query. I installed the freetds-0.91-15 driver on my Oracle Linux and configuredĀ unixODBC-2.2.11-10.el5 appropriately. All went well and I soon had the first results on my page. My next task was to create a simple enough query that would ‘count’ some database rows. Simple enough, right? Well, at least up to the part where I ran into this error:

No tuples available at this result index in […]

All the posts I found referred to multiple result sets in which ‘odbc_next_result($result);’ should be the resolution. The weird part was, pasting of the echoed $sql into the MSSQL query box would give me the desired effect. One result with an count of the rows. The same SQL in the PHP script would give me the ‘no tuples’ error. I nearly fixed it the ugly way (counting the rows in an php while that would work) when I had an insight.

In the mssql output i noticed NULL fields in the table column that I was counting. So i figured, might counting NULL values somehow trigger the ‘No Tuples’ error im getting?

So this is what I ended up testing:

SELECT COUNT([sdk].[Events].[FirstName]) as Counted FROM [sdk].[Events]
WHERE [sdk].[Events].[PeripheralName] like '%Search%'
AND [sdk].[Events].[EventTime] BETWEEN '1' AND '31'

Which resulted in : Warning: odbc_fetch_array(): No tuples available at this result index in /var/www/db.class.php on line 52

SELECT COUNT([sdk].[Events].[FirstName]) as Counted FROM [sdk].[Events]
WHERE [sdk].[Events].[PeripheralName] like '%Search%'
AND [sdk].[Events].[EventTime] BETWEEN '1' AND '31'
AND [sdk].[Events].[FirstName] is not null

Which resulted in an working count query.

Fix the inline images -bug- in glpi knowledgebase (htmLawed.php)

GLPI-0-84-8 FIX

GLPI uses the htmLawed filter to clean inserted HTML code. Documentation on this framework can be found here: http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Problem with this framework in GLPI is that it does not match image tags properly when they contain inline base64 information.

Here is a simple fix to overcome this problem. The htmLawed.php file can be located in %glpi_root%/lib/htmlawed/htmLawed.php. Open it with your favorite editor. Next locate line: 47. Somewhere arround that area you should find the following.

Web - sftp___nagios@glpi.amis.nl_var_www_glpi_prod_lib_htmlawed_htmLawed.php - A_2013-10-29_12-34-30

Add ‘data’ at the end of the marked line.

$x = (isset($C['schemes'][2]) && strpos($C['schemes'], ':')) ? strtolower($C['schemes']) : 'href: aim, feed, file, ftp, gopher, http, https, irc, mailto, news, nntp, sftp, ssh, telnet; *:file, http, https, data';

The above will stop htmLawed from adding disabled: to the data: in the src=”” tag.

The next step is a bit trickier.

Now we need to actually change the hl_tag function. In the file locate the hl_tag($t) function somewhere around line:407. In this codeblock we are looking for the regular expression marked in the image below:

Web - sftp___nagios@glpi.amis.nl_var_www_glpi_prod_lib_htmlawed_htmLawed.php - A_2013-10-29_12-38-10

This is the expression that doenst match the valid <img> tags within the htmLawed. We dont want to create leaks here, so all we need to do is introduce an exception for our images. You can do so by replacing the text with the following:

Web - sftp___nagios@glpi.amis.nl_var_www_glpi_test_lib_htmlawed_htmLawed.php - A_2013-10-29_12-49-27

In code:


if(!preg_match('`^&lt;(/?)([a-zA-Z][a-zA-Z1-6]*)([^&gt;]*?)\s?&gt;$`m', $t, $m)){
if(strstr($t, 'data:image')){
return $t;
}else{
return str_replace(array('&lt;', '&gt;'), array('&amp;lt;', '&amp;gt;'), $t);
}
}elseif(!isset($C['elements'][($e = strtolower($m[2]))])){
return (($C['keep_bad']%2) ? str_replace(array('&lt;', '&gt;'), array('&amp;lt;', '&amp;gt;'), $t) : '');
}

After this, the images should show up just fine

GLPI - Knowledge base_2013-10-29_12-50-51

I hope this was helpfull šŸ™‚