RP Installation MySQL error on existing zipData Table
 

Step 3: MySQL error reported: [CREATE TABLE zipData (zipcode varchar(5) NOT NULL default '', ZipCodeType char(3) NOT NULL default '', City varchar(128) NOT NULL default '', CityType char(3) NOT NULL default '', State varchar(64) NOT NULL default '', StateCode varchar(5) NOT NULL default '', AreaCode int(5) NOT NULL default '0', lon varchar(8) NOT NULL default '', lat varchar(8) NOT NULL default '') TYPE=MyISAM]
Result: Table 'zipData' already exists


Hmm... I thought it was supposed to use rp_ (as I specified) for any tables it creates anyway?

What if a user already had a (non-PhotoPost/Classifieds/RP) zipData table here? I guess zipData for PP products wouldn't get installed in that case.

Yes this is your issue you own classifieds and that table already exists

NO WORRIES

Oh I figured it wasn't a problem... since the table structure would likely be the same across all these apps.

I'm just saying you guys might want to add a routine to check that to avoid people who don't know that it's not a big deal from coming in here & creating a post or an email over it.

Well there would be no way to fix that as its not really an issue.

It is just one of those things that like you noticed it since the table exists and came here to post. If someone posts about it we can answer.

You would get similiar issues if you run install twice or an upgrade twice just a mysql warning saying it exists

Of course it can be fixed.

It's a seperate sql file that you import right?

Why not import all the RP sql, then before attempting to import the zip.sql file you would just check to see if it exists & if it does, confirm that the a couple or all of the fields within it are what you expect - then don't attempt to import it & you wont get the error.


BETTER YET, if it was doing what it was _supposed_ to be doing, then it wouldn't have gotten the error in the first place.

It should have created the database as rp_zipData since ALL tables created/imported by RP should use the rp_ table prefix that I was prompted for and specified.

The reason for using those table prefixes is to keep things oragnized and also to keep things like this from happening.

In this case it happened to be OK because the existing table was another of your own and interchangeable - but if I had another mod to my VB3.5.1 with a table named zipData this would not have been the case.