issue with godaddy database connection

Please go easy on me because I mention Go Daddy :wink: (I'm making the most of the resources I have available to me at the moment and if you get it set up right...grid & linux environment...they have been ok. And OCCASIONALLY you get a tech that seems to know a little bit)

Situation:
I was building our ZC1.3.9h site on another GD account. It is set up on a Linux server / Grid environment. Things worked fine.

Now I am trying to transfer everything to our live site. It is currently a windows platform (which I'm thinking is not a cause for my problem) I need to stay on the window platform until i confirm everything is set up because our current site uses a MSSQL d-base that is not supported in a Linux environment.

I moved all my files, exported d-base, and imported. System was broke. I did a GD one-click install in a sub-directory, and that one worked. I then pointed my manual installation to the GD one-click database and my install now works (admin and front end resolves). Point back to mine and nothing. The tables in GD one-click have a prefix of zen_ (and yes i updated the configure.php file accordingly for my scenarios). I later imported my tables (which have no prefix) into the GD d-base. My tables do not allow the page to resolve yet the GD install tables do? Any thoughts on what could be happening to make a simple export import not work? I did follow the instructions posted elsewhere in Zen-Cart regarding the options to click when exporting. I'd like to keep my format because the configure file states that the preference is without a prefix.

Thanks

I'm confused... what site is using a MSSQL dbase, and what are you trying to do with that database?

schoolboy:

I'm confused... what site is using a MSSQL dbase, and what are you trying to do with that database?

Sorry for the confusion. Our current live site is not Zen and runs off a MSSQL d-base. If I go ahead and switch that domain over to a Linux server, I would have to basically go ahead and kill our current live site. I would like to leave that site & MSSQL up and running until the ZC site is functioning on the same domain.

Well... there is no real big issue with the dbase prefix. we have sites WITH and WITHOUT prefixes... and they all work just fine.

If the dbase WITH prefixes works... then just leave it at that...

Here's what I've done in the past... DrByte will probably "scold" me for telling you this, but it's never failed me in the past.

In your initial ZC setup, go to phpMyAdmin, and export the database as a screen-dump of text. (So you can see it in a scrolling textbox in phpMyAdmin.

Highlight the whole block of text (or rather, sql) Use COPY <ctrl+c>

Then, PASTE <ctrl+v> into a blank notepad file on your computer.

SAVE AS a xyz.sql file, and make sure to set the collation as UTF8 as you save in notepad.

Then, go to your RECENT database (the one with the PREFIXES) and MAKE A BACKUP.

Then... DROP all the tables in it. (Remove them, so the dbase is empty).

Then, open up that notepad sql file and grab all the "text".

Go back to phpMyAdmin and click the SQL tab at the top.

PASTE the sql into the input frame and click "GO"

Tell me what happens.

It somewhat worked.

I have messed around further and tried your technique (which helped speed up one process of removing the prefix by doing a find and replace in notepad). What I have been able to do is:
1)Export to screen the working GoDaddy d-base
2)Copy&Paste into notepad
3)Find & Replace prefix
4)Copy&paste into sql tab in My d-base

Doing the above steps allowed the site to now resolve. However if I try to update the data with that from my zen-cart test site...it crashes again. I'm still testing different methods for getting the data into the working system, but I really curious as to why this would be happening to possibly prevent future issues.

Thanks for the help b/c that is definitely a good trick to know and hopefully Dr. Byte won't scold you too bad.

I don't think anyone has ever gotten an install on a GD Windows server to work.

schoolboy:

Here's what I've done in the past... DrByte will probably "scold" me for telling you this, but it's never failed me in the past.

In your initial ZC setup, go to phpMyAdmin, and export the database as a screen-dump of text. (So you can see it in a scrolling textbox in phpMyAdmin.

Highlight the whole block of text (or rather, sql) Use COPY <ctrl+c>

Then, PASTE <ctrl+v> into a blank notepad file on your computer.

SAVE AS a xyz.sql file, and make sure to set the collation as UTF8 as you save in notepad.

Then, go to your RECENT database (the one with the PREFIXES) and MAKE A BACKUP.

Then... DROP all the tables in it. (Remove them, so the dbase is empty).

Then, open up that notepad sql file and grab all the "text".

Go back to phpMyAdmin and click the SQL tab at the top.

PASTE the sql into the input frame and click "GO"

Tell me what happens.

The biggest problem with doing copy+paste like that is the risk of characters being incorrectly translated between character sets. A properly executed export is often safer. Granted, if NONE of your data uses any extended non-english characters then it's somewhat moot, and of course then there's no reason that the export-to-file wouldn't work exactly as we recommend.

The issues at hand here, making any of these suggestions remotely necessary, are caused by the inferior tools provided by the host.

idc1:

3)Find & Replace prefix
THAT is a dangerous operation. You said earlier that you were trying to remove a "zen_" prefix.
But, if you blindly did a global search-and-replace, then you'll be back again asking for help when all your admin configuration menu screens don't work because they're throwing PHP errors.

There are MANY places where raw database content contains "zen_" references that have NOTHING to do with database tablenames, and ALL THOSE references should be LEFT ALONE.

A person with a strong understanding of database concepts and SQL statements may "get" it and maybe not replace references that are in the data part of the records ... but the vast majority of people reading posts here and blindly "trying" what's posted, WON'T get it, and will end up damaging things ... only to have to come here and be told to restore from backup and start all over again because they've wrecked their data.

So ... USE AT YOUR OWN RISK if you're considering doing ANY direct editing of raw SQL statements, including search-and-replace of "prefixes" or ANYTHING.

DrByte makes a really good point regarding a blanket "Find and Replace"

Also as an update. I took a leap of faith feeling certain the problem was Windows vs Linux. Viola!

Just my two cents. GoDaddy seems o.k. but you have to use LINUX. This was the 2nd time the windows platform gave me some sort of trouble.

Viola!...cue the music :)

Sorry, I couldn't help it...

gjh42:

...cue the music :)

Sorry, I couldn't help it...

Very nice :) Maybe next time I'll put my vowels in the right place.