I am trying to move my local test site to my webhost.
This is what I have done so far.

1) Made new database on remote with same name, username and password as local.
2) Dumped all the table structure and data from local to remote db.
3) ftp'd all files from local to remote keeping same file structure.
3) Changed includes/global.inc.php to suit new locations, I have even carried out a dummy auto install that works to check the rootdir etc

This should be possible right!
I do not have to carry out an auto install on the remote to write something to the db if I have already done it locally and copied over all the tables, do I?


Wouldn't mid a bit of moral support here, before I screw everything up.

Cubecart 3.04 with custom skin.

Oh yes, the error I get both for Cart and Admin is

1146: Table 'kuckooco_cube.CubeCart_config' doesn't exist
QUERY = SELECT array FROM CubeCart_config WHERE name = 'config'

I know this means it cannot find the db but why not?
I have searched for this but cannot find a coherent answer.

Thanks
Frank

Hi Frank,
I'm newish to CubeCart but am quickly getting to grips with it. Yep I think there is something about the cubecart_config table which doesn't travel well!

The way I've been doing this is to do a fresh install on live server with same passwords etc, export all tables (data and structure) from the local copy except cubecart_config and import into your live copy.

FTP up your images and skins (and other files if you've been making modifications).

That should be about it!
-Simon.

Does anyone know if or why this is the case, that you cannot carry out a complete database dump from one domain to another because of the config table having some data in it that only relates to the original installed site?
I thought that the only place the db parameters were held in was the global.inc.php file and if these were correct it was ok.

Thanks
Frank

If this is indeed true, I would tend to think a redesign might be good for this code that requires instance specific data in a DB instead of a config file.

Hopefully this is a untrue rumor

Yea sorry guys, I don't want to be starting a rumor. Just going on what happened to me when I tried this last week, and also an old article in 'Web Designer' magazine where they dropped the config table to upload to live.

What I posted before was an alternate method rather than an answer, Frank sounded like he needed a reply!

I've just actually done this in reverse now, exported from live to import into my development area and it worked ok - config table and all.

Could it possibly be a MySQL version mismatch, I'm using a newish version of Xampp which comes with :
phpMyAdmin 2.6.4-pl1 & MySQL 4.1.14

Live server is : phpMyAdmin 2.6.0-pl3 & MySQL 4.0.23-standard.

Or you could try a live install and compare the global.inc.php that gets produced to the one you created manually, could be one of those typos that you just can't see for looking! or a hidden dodgy character....

Thanks,
Simon.

Simon you may have a point about the mySql version,
My versions are:
Local ver 4.1.10a - nt
Remote 4.0.25 standard

I had already remotely installed 3.04 temporarily and used that global.inc file for the manual install, so the data was ok in that file.

Anyway, I decided to bite the bullet and auto install 3.05 and insert my db data manually, and copy all my modded files.

This still doesn't solve the problem of transferring the config table but at least I can get on.

Thanks
Frank

If I had to make an educated guess, I'd go for the PHP and MySQL version differences. The config table has fields in it that are serialized and base64encoded. The different software versions could very well get different results. While it could always read it's own, it may not read another server's.

It would not be a big deal to take Brooky's config editor tool and dump the contents cleanly from one server, then take that dumped info and put it back into a proper config table on the new server.

As people start to change hosting companies, I can see this being a necessity. Maybe in our spare time, we'll do something like that.

This issue is also happening when you are working on a WAMP (Windows Apache Mysql PHP) for developping your website, and when you are uploading it for production on a LAMP environment (Linux Apache Mysql PHP).

The answer for CubeCart not being able to find the database is simple : in windows (WAMP) there is no character break check. So Windows don't make any difference between a C and a c. And this is where we got a problem, when we export the database from the WAMP system (so the one running on windows) the table are like that cubecart_category, cubecart_inv, etc... but CubeCart need them as CubeCart_category and so on, because Linux as a character break check.

In the end, the problem is solved by renaming all the table in the mysql dump from windows.

Also, it can be due to some specific problem with certain versions of phpmyadmin/mysql. But i'm giving this solution just in case.

Best Regards,
Matt.

Matt - thats exactly the problem, I noticed when I did the fresh install of 3.05 on the remote host that I had two sets of tables in the db, one set starting with C and the other with c, I wondered why they were not causing each other problems, obviously the Linux system was ignoring the c tables. That would also explain why Simon could not copy to his host but could copy back to his local machine ok.
Not ever used Linux so I didn't even think of it.
Thanks for saving me this hassle in the future.
Frank

I've just enounted this issue too. Surely it would make sense to drop the upper case C's and make life easier for the many developers who use a local WAMP platform for testing?