PlanetCatfish.com

I am getting this error when I try to add data to the Conta pectinata page (species just added). I am guessing it has something to do with the nature of data I have added in a particular field but I am unable to figure out what exactly it is.

It does indeed seem like it's something going into the Literature (aka "references") field. Any chance you can post what you was using for this field?

--
Mats

<em>Conta pectinata</em>, a new erethistid catfish (Teleostei: Erethistidae) from northeast India
Heok Hee Ng.
Range extension of <em>Conta pectinata</em> Ng, 2005 (Teleostei: Sisoridae) in upper Brahmaputra River drainage in Arunachal Pradesh, India, Lakpa Tamang & Shivaji Chaudhry.



I am guessing its the '&' symbol???

I'm pretty certain the & is OK. It looks like it may not be "plain text" from the "\xnn\xmm\xpp" bits at the beginning of the error message quoted bit. Would you be able to copy and paste the text of the actual error message (I think you've downscaled the picture, so I can't quite read it properly).

Otherwise, I'll have a play when I get home (don't want to edit an existing species... ;) )

--
Mats

Replaced '&' with 'and' but the error still persists.


General Error
SQL ERROR [ mysql4 ]

Incorrect string value: '\xEF\xAC\x81sh ...' for column 'literature' at row 1 [1366]

An SQL error occurred while fetching this page. Please contact the Board Administrator if this problem persists.
Please notify the board administrator or webmaster: [email protected]

I've figured it out:
catfish
has the "fi" as one character (symbol or whatever you want to call it. Try selecting the "f" and you'll notice that it will only select either both f and i or none....

To fix:
If you remove the fi and write that out as f and i, rather than the single fi symbol.

I will see if we can make a permanent fix in the code that deals with this.

--
Mats

\xnn is a way to represent the hex value (nn) of an ASCII character outwith of the normal set. In my view, this should fail gracefully rather than rely on tricksy conversion/encoding etc. Or, to put it another way, don't want extended ASCII in the dbase.

Jools

Jools wrote:\xnn is a way to represent the hex value (nn) of an ASCII character outwith of the normal set. In my view, this should fail gracefully rather than rely on tricksy conversion/encoding etc. Or, to put it another way, don't want extended ASCII in the dbase.

Jools

We don't want extended ascii, or not UTF-8 - the "fi" ligature is valid utf-8, and we may want other UTF-8 characters, such as the ü in Isbrücker or í in Río Amazonas.

I agree, it should definitely fail gracefully in case of something that doesn't actually work, but I'd say it's correct to accept some types of UTF-8 "extended characters".

Unfortunately, my promise to look at this was delayed by a friend's daughter calling on my mobile with "My dad's tank is full of dead fish, and dad said to call you...". So I spent an hour or so cleaning my friends filter and changing a bit of water. Fish looked much happier when I left... I then had to do some more soldering for special wires I'm doing for work - can't bring the soldering iron to work, as it's not PAT tested and elf and safety officials probably don't like hot things in an office anyways...

I'll have a look now...

--
Mats

I have looked at this and can reproduce the problem. Thought I had a fix, but it doesn't appear to work right now. Will have another look at it tomorrow - time for bed now...

--
Mats

What I meant above is that shouldnt such characters be stored in the dbase as HTML entities rather than in their specific character set?

Jools

Jools wrote:What I meant above is that shouldnt such characters be stored in the dbase as HTML entities rather than in their specific character set?

Jools

Except, there is no 'fi' ligature in HTML, as is there no support for a vast number of other Unicode characters. In the posts above, the u-umlaut are not &uuml;, but just a single character, and likewise the fi is just a sequence of UTF-8 encoding, not a &# or &filigature; or whatever it should be as HTML code. Or do you mean it should be written as the corresponding &#nnn number?

--
Mats

This is still outstanding, but I'm not sure if it's actually required to be fixed. It's a year and half since we saw this, and I don't believe we've hit it again. It's annoying, but is it worth spending time fixing?

--
Mats

Mats,

Well, your recent Danio update appeared also to fail from the same issue?

Jools

Jools wrote:Mats,

Well, your recent Danio update appeared also to fail from the same issue?

Jools

Dario, not Danio ;)

But yes, that appears to be a problem, so perhaps I need to do look at it. Awaiting the DB dump tomorrow.

--
Mats

Ok, the vetting side is fixed in R1297 (I also made one other small update to the fishbase fetching code, as it used the same rather obvious name for a similar function).

It may need the same treatment in the data_sub.php...

--
Mats

R1298 contains a fix for "missed one place where it was used" from the original code.

R1299 contains the fix for the original data-sub problem. It should now be fine to enter almost anything in a datafield that you could possibly type on a computer. Whether it displays correctly at the other end is a somewhat different matter, but at least it shouldn't give any direct errors.

--
Mats

Well, it got the update in, but I don't think it looks right...

Jools

That post refers to before the R1302 fix, right?

--
Mats

Mats,

Nope, R1302 (and R1303 is now online and issue persists). I will email you a screenshot...

Jools

So, I think R1304 fixes this.

--
Mats

Yes, resolved.

Jools