Matt Rajkowski wrote:

There won't be any impact by removing the UNIQUE of lookup_project_permission.

Hopefully this also applies to the table...

-- Name shortened from lookup_document_store_permission
CREATE TABLE lookup_doc_store_perm (
code INTEGER NOT NULL,
category_id INTEGER REFERENCES lookup_doc_store_perm_cat(code),
permission VARCHAR(300) UNIQUE NOT NULL,
<snip>
):

...the UNIQUE on the field "permission" must be removed..

???

Matt,

Another UNIQUE on a large field, issue though this one may require some consideration.. Since there is no primary key and I can see it might require "unique" ness..

CREATE TABLE business_process_log (
process_name VARCHAR(255) UNIQUE NOT NULL,
anchor TIMESTAMP NOT NULL
);

..for Firebird this would either require and "id" for a primary key or using the timestamp as a primary key.. if you need "uniqueness" for this event.

John..

John,

[lookup_doc_store_perm] removing UNIQUE is fine... the application does not rely on this being unique.

[business_process_log] removing UNIQUE is fine... again, the application will maintain the process_name being unique. Using the TIMESTAMP field wouldn't work because there are several processes running in a thread and the execution time is recorded here. Slim chance 2 would have the same timestamp, but they can.

As for the above, I plan to compare them with the existing scripts and any differences (a bunch) will be highlighted and reviewed thoroughly once all scripts are submitted.

In the meantime, if you have any questions, fire away.

OK.. I'm finishing up on the last three scripts.. Hopefully I'll have those finished in the next couple of days.. (lot of other tasks to juggle..)

John..

Good new.. the last three scripts had little or no adjustments so I was able to get through them quickly...

FYI.. This project, thus far has, involved over 60 hours at my end. More than glad to do it.. but a bit more than your first estimates..<evil grin> But of course you have had to, and will have to, spend a lot of time.. Just wanted to you know how much I have done..

If you need me to create a list of the several tables that got "shortened" let me know (they as will as the Sequences are marked in the scripts with the "-- Old Name:" comment.)

Let me know if there is anything I can do to keep the ball rolling.. We are eager to get started using CentricCRM !!!! (Got a new machine sitting and waiting...)

BTW.. Have you folks considered using the "restore" (gbak) feature of a database to do the setup..??? I use this a lot of my database for my clients using Firebird..

John Moore
SonicSpider LLC

John... thanks for working through this. The scripts are typically the most demanding part and I appreciate the effort. I think that others will find these useful as I have noticed a general interest in Firebird.

Looks like there are still some integration challenges due to the changes we agreed on and we have a few things to do with them now... the next steps on my side include:
1. Comparing the scripts against the base set and testing the scripts
2. Adding any application specific code to support Firebird functions (we've already started this)
3. Internal testing to see if everything is all right
4. Compiling a beta version for general testing

Thanks again! Everyone can expect some progress reports as we go through these steps and we might have some questions.

- Matt

Matt,

Sounds great!!

Obviously, I'm eager to keep the ball rolling, soooo holler if there is ANYTHING I can do to speed it along..

BTW.. Where might you be posting these announcements...????

John..

Matt,

Any progress reports....?????

John...

I guess here is as good a place as any for feedback.

Got the scripts copied into the installation and reviewing them alphabetically...

Only noticed the following so far:

BOOLEAN type in Firebird is being set to CHAR(1), which is good.
However, in cases of mapping TRUE/FALSE with DEFAULT '1'/DEFAULT '0' I think they are switched.

DEFAULT '1' is TRUE

Matt Rajkowski wrote:

BOOLEAN type in Firebird is being set to CHAR(1), which is good.
However, in cases of mapping TRUE/FALSE with DEFAULT '1'/DEFAULT '0' I think they are switched.

DEFAULT '1' is TRUE

OK, whatever...<G> I had always remembered it as 0/1 = true/false, but since I don't used it much.. I just looked it up and you are right.. Obviously I miss remembered.. (made the common error of assuming there was "common sense' involved..<G>)

Great is is moving along.. We are antsy to get this up and running, so let me know if there is ANYTHING we can do to keep it going..

John....