By the way, greetings everyone!
This was my first post. I was composing it when by accident I sent it instead
of saving it, so my greetings did not make it into my post. Forgive me, I did
not meant to read ignorant.
Migration might be too strong a term - I don't want my Firebird database to
bear too much resemblance to an old Paradox database. The database might serve
similar logical purposes, though. The domain advice is good in general -
char(16) character set octets, for example, would probably be a go
The case-insensitive collation option sounds the most seemless. I might have
to choose character sets more carefully - the DB I tested with was ISO8859_1
for a default, and I couldn't find a CI collation for it (maybe I needed to
look harder). The second is basically a simpler version of what
Sorry - it's been a long time since I last posted. My OP was verbose, lengthy
on preamble. I've gotten too accustomed to emailing users. Thanks.-MB
On 17 Aug 2014 12:05:08 -0700, "vogonjeltzprostet...@yahoo.com
[firebird-support]" wrote:
> This was something I would resort to years ago in Paradox. Suppose I
had
> a table CORPORATION with columns S_KEY INTEGER, SUBSIDIARY_NAME CHAR(50)
> and a table EMPLOYEE with columns CORPORATION_S_KEY INT
>The problem comes with the second. (1, 'Bob Jacobs'), (2, 'Bob Jacobs'), (3,
>'BOB JACOBS'), and (4, 'bob jacobs') constitute an acceptable set of rows;
>(2, 'Bill Hafner') and (2, 'BILL HAFNER') do not. That is, given a value for
>CORPORATION_S_KEY, there shouldn't be case-variants for the N
Are you migrating an existing database from Paradox, or are you working
on a new Firebird database?
I am just learning Firebird, and I do not have the solution perse, but
maybe these are going to help you or others a bit.
- Make sure your database is using the right character set for your
