Subject Re: Dialect problem??
Author sllimr7139
> Don't you know what is the default character set of your database?

It's not my database, it's a clients and I've run utils like gstat and
a few others to try and determine the character set but so far have
been unable to determine what the database default is. The blob field
and the varchar field are on the same table. My client created the
database and the blob field, I created the varchar. I didn't specify
the character set for the varchar field so it has to be using the
database's default and I don't know how to find that information

> As to the valid characters, you can google on the character set
> name usually, to eventually find a chart for the particular code
> page that the character set implements.

Ok, thanks. I'll do that once I figure out what the character set is.

> Now, that sounds weird. Are you talking about the "back-tick"
> character? If so, it's certainly a special character on Linux
> and probably has to be escaped in some environments. (But it's
> ascii 96 so it can't be both that and hex 92...ascii 146 is a
> different character entirely, the uppercase AE diphthong
> character) Could it be the left quote of a Word "smart-quotes"
> single quote pair?

That's the character (AE). If you take a closer look at the data I
posted yesterday, copy it to notepad and change the font to terminal,
you'll see that's exactly the character I'm refering to. That's how I
found it yesterday. And your right about the Word thing, both the
client and myself figure that someone in his company copy and pasted
the text out of an (MS) email reader or Word document and that's how
it got in there. But we're only guessing at this point.

> If (by a long shot) Delphi is converting the back-tick (or
> whatever it is) to a regular apostrophe (ascii 39, or #39 in
> Delphic!) then you MUST escape it in Firebird SQL the same way
> you have to in Delphi, because it is the string delimiter in
> both languages. To escape the apostrophe you double it.

Delphi isn't converting it. I can confirm this.

> set myvarchar = 'O'Flaherty's Pub' will fail
> but
> set myvarchar = 'O''Flaherty''s Pub' succeeds. (That's double
> apostrophes, not double-quotes).
>
> Now, Delphi has the function QuotedStr() which will take care of
> these for you. It would be worth at least a try - it wouldn't
> be out-of-the-way for Delphi to try apostrophising the smart left
> quote or the back-tick...

This only needs to be done if your trying to insert a constant string
into the sql statement itself. If your using IBObjects and the
parameter capabilities you don't need to use the QuotedStr function.
If you do you then get leading and trailing apostrophes when you pull
the data out of the database. (I assume that either IBO does this for
you or it has to do with the way the paramters work in the client
library)

> You're not looking for "valid characters for Firebird", you're
> looking for "valid characters for the codepage being used by
> database and client".

Ok, thanks.

> Probably not - though there is a bit of info on character sets
> at the end of the Language Reference. To publish every
> code-to-image mapping for every codepage would be a book on its
> own.

I did run into that, but I didn't find it very helpful. Is there a
way to determine the codepage(s) in use for a database or the columns
of a table? Maybe a DML query? What about looking at a system ($RDB)
table?

Ryan.