[ic] Upgrading to SQL Database

John Beima interchange-users@icdevgroup.org
Wed Sep 25 13:22:01 2002


Quoting "Barry Treahy, Jr." <Treahy@MMaz.com>:

> John Beima wrote:
> 
> >Quoting "Barry Treahy, Jr." <Treahy@MMaz.com>:
> >
> >>  >    I have a theory as to why it is problematic sometimes, at least
> for
> >>  >postgresql, but I am not certain that I am correct.  It looks like the
> >>  >structures in dbconf/pgsql are missing fields that are in some of the
> >>tables
> >>  >that come with the Foundation store.  So when interchange tries to use
> >>this
> >>  >to create tables there are subsequently errors when the attempt to
> >>import
> >>  >the corresponding txt files is made.
> >>  >
> >>  >
> >>I'm not sure that this is so much the case as I believe I read that IC
> >>defaults to a CHAR(128) field for each undefined columns.  What kept
> >>biting me in the back side were fields I wanted more control over,
> >>specifically numeric or decimal fields, and that IC (or perhaps mysql)
> >>would choke and die on the load if the field were null which is not a
> >>behavior I found real friendly...
> >>
> >>    
> >>
> >You have all the control you need. The problem is YOU are not updating
> your
> >dbconf files.
> >
> >This should ALWAYS be done, no matter if you are using gdbm, MySQL,
> PostGRESQL,
> >or Oracle.
> >
> >If you make ANY format change to your database structure, Interchange just
> can't
> >GUESS as to what it is, you have to tell it.
> >  
> >
> Hi John,
> 
> yes, I know that but the IC docs do state that:
> 
> " The table will be created. If there are COLUMN_DEF specifications in 
> catalog.cfg, they will be used. Otherwise, the key (first field in the 
> text file by default) will be created with a char(16) type and all other 
> fields will be created as char(128). The table creation statement will 
> be written to the error.log file."
> 
> which was what I pointed out to the prior post about missing fields... 
>  I was simply attempting to point out that if you are specific about 
> columns, in particular making them numeric, decimal, and so on, that 
> either/or IC/mysql does not like to see rows with null columns for  
> these explicitly defined fields...
> 
> Barry

If what you mean by this is if the column is them missing from the text file, IC
complains, or just doesn't create it, you are correct. I don't even think it
complains. It just simply doesn't create it.

Which makes sence. Defaulting this way as a fail safe.

You NEED to keep these files in sync. with your DB files.

If you do that you will make your life MUCH easier. Especially when creating
back-ups to your database files, or converting from one db format to another.

Another thing you may wish to try, is if your data ever contains control
characters, to use the "%%/%%%" file format instead of the TAB or CVS.

With the "%%/%%%" format you can export, drop, and re-import the UserDB without
a hitch.


John Beima
jbeima@palb.com, support@alocalagent.com, and support@alocalchurch.com


//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
\\                                                                    //
//                                                                    \\
\\ ADVANCED INTERCHANGE HOSTING - $15.00 Per MONTH                    //
// Generic Web Site Hosting - $10.00 Per Month                        \\
\\ Includes Unlimited E-Mail Accounts With Many Options!              //
// Includes one .com, .net, or .org domain!                           \\
\\                                                                    //
//                                                                    \\
\\ Affordable Web Pages / P.A.L.B. Systems                            //
// www.affordable-web-pages.com                                       \\
\\                                                                    //
//                                                                    \\
\\ 11639-122 Street, Edmonton, Alberta, Canada, T5M 0B6               //
// Phone: (780)451-1086 - Fax: (780)447-4760                          \\
\\                                                                    //
//                                                                    \\
\\ 2713B Spring Place SW, Decatur, Alabama, United States, 35603      //
// Phone: (256)341-0543 - Fax: (256)351-7297                          \\
\\                                                                    //
//                                                                    \\
\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//