Removed local database from phpmyadmin by mistake

Hi Rod,
I'm back, lol. I need some help please. ( with my test/local install of zen cart - not my live zencart )
The issue I was having in regards to not being able to work the phpmyadmin ( local ) has been fixed via me deleting everything and starting from scratch again. I now have a working url ( store ) and a fully functional phpmyadmin on my localhost. What I would now like to do is import my saved sql table/files into the now fresh install of zen cart. I did try it before and stuffed it all up. I imported the saved sql files and it put them on there but when i clicked on the store refresh button nothing had actually changed, in my attempt at fixing/solving this problem i stuffed it all up and had to re install the zen cart from scratch once again.
I am now asking for help, it would seem this should be an easy enough task to do but I am missing something here, does anyone have any help/suggestions for going forward here please.

Thanks in advance.
Ash.

Soulkreed:

but when i clicked on the store refresh button nothing had actually changed,

This is common with many changes to the store, on account of the fact that much of the data is cached.

The basic rule is If you make a change that doesn't have the effect you are expecting, it is because the data is being fed from a cache, or the change you made wasn't the change that needed to be made.

Until proven otherwise always assume it is a cache problem before looking for other causes.

Cheers
Rod

Hi Rod,
I have performed a ( ipconfig/flushdns ) also a ( net stop dnscache ) and a ( net start dnscache ) all from the command prompt window and I am still not seeing any results on my local test zen cart store or the admin section.

Any clues please?
Cheers, Ash.

Soulkreed:

Hi Rod,
I have performed a ( ipconfig/flushdns ) also a ( net stop dnscache ) and a ( net start dnscache ) all from the command prompt window and I am still not seeing any results on my local test zen cart store or the admin section.

Any clues please?
Cheers, Ash.

Firstly, it is your web-browser cache that possibly caused your original 'no change' symptom, rather than DNS cache.

Secondly, just clearing the cache(s) now isn't going to solve the issue if you had already moved on and made other changes. This is simply compounding the problems.

You need to go all the way back to

Soulkreed:

" now have a working url ( store ) and a fully functional phpmyadmin on my localhost. What I would now like to do is import my saved sql table/files into the now fresh install of zen cart.

Then do the import, and if you don't see the result of the import you will need to clear your browser cache BEFORE moving ahead with other changes.

Cheers
Rod

Ok, I have cleared the browsers cache and went back and deleted the zen cart install and re-installed it again and uploaded the saved SQL backup files and still nothing has changed in my store front.
I know that the files are there as the files amount has gone from zencart 93 to zencart 190 in the drop down box in the left field of phpmyadmin.
Ok, now if I have done these things correctly that should cancel it out as being a browser cache problem?

Ok, what's next on the check list please?

Cheers mate. ( by the way, merry xmas and a happy new year and a big THANKING YOU for all your help )

Soulkreed:

Ok, I have cleared the browsers cache and went back and deleted the zen cart install and re-installed it again and uploaded the saved SQL backup files and still nothing has changed in my store front.

Although no longer relevant (due to further information that you have supplied), it is at this point where you would need to be clearing your cache.

Soulkreed:

I know that the files are there as the files amount has gone from zencart 93 to zencart 190 in the drop down box in the left field of phpmyadmin.

To avoid confusion, these should always be referred to as 'database tables' rather than files.

Soulkreed:

Ok, now if I have done these things correctly that should cancel it out as being a browser cache problem?

Not in itself, but the fact that your database tables have doubled tells us that you haven't really imported any 'new' data for the store, you have created a complete new set of tables that the store doesn't 'know' about.

Soulkreed:

Ok, what's next on the check list please?

I'm guessing that the doubling up of the database tables is caused by a prefix mismatch. On your live server your database tables are prefixed with 'soulk_' (or something like that), but on your local machine you are probably using 'zen_' or perhaps no prefix at all.

The solution is to ensure the correct prefix is specified in your configure files.

My personal approach would be to re-install zencart (again) on the local machine, and ensure I use the same prefix that is used on the live server.

Cheers
Rod

I have done as you said, I have deleted and re-installed everything and have made the prefix match the live server. ( soulkr_ ) ( the prefixs in the configure files both matched, they are both soulkr_ and I changed the prefix in the install to soulkr_ as well ) the only thing I am not sure about is the SQL table file backup itself, am i to change anything in that at all ?, I had a look and couldn't find anything like soulkr_ or zen_ in there using a text editor.
I am still getting the doubling up of my database tables from 93 to 190. There is no change reflected in my store front.

Ash.

Soulkreed:

I am still getting the doubling up of my database tables from 93 to 190.

Regardless of anything else, this is still the issue you need to resolve.

The first table in a default zencart database with a "zen_" prefix is called
"zen_address_book"

In your case it will be "soulkr_address_book" (before any imports). After the import you'll find that there is another "??????_address_book.
What is the name you get in the place that I've used question marks?

Cheers
Rod

I am looking in phpmyadmin at the tables and there is one address_book at the very top and one soulk_address_book about half way down.

I cannot find any other address_book anywhere, just these two.

Cheers.

Soulkreed:

I am looking in phpmyadmin at the tables and there is one address_book at the very top and one soulk_address_book about half way down.

This is your prefix mismatch.

One of those entries is from your local installation, the other is from your imported tables. (You'll find similar duplication with all the other tables).

You must make these table names match (and/or edit the local config files to match the table names created by the import).

Cheers
Rod

The local config files ( admin/includes/configure.php and includes/configure.php ) both have soulk_ in the DB_prefix line. If they are indeed the original local files and not the imported ones that have overwritten them.
If they match the imported SQL database tables DB_prefix ( which they do from what i can see ) then it should work yes?
What I don't understand is if the SQL database files that I have imported in that have doubled up ( meaning the system doesn't know about them yet/can't put them where they need to be ) are reading the same DB_prefix as the local configure.php files then why isn't it working?
If the local configure.php files say that the DB_prefix is soulk_ then why don't the local database tables in phpmyadmin also reflect these same settings so to speak?
I am missing something here aren't I?

Cheers mate.

I am looking at the SQL database backup table files in my text editor and it would appear that all of these files headings do not have soulk_ anywhere at all. This would suggest that I have been thinking that the imported files were the ones that had soulk_ before them but if I am correct it is the other way around.
If this is the case do i go through the SQL DB tables files and change everyone of them with my text editor one at a time to read soulk_ or is there another faster way or have i gotten my assumption wrong about this?

Soulkreed:

The local config files ( admin/includes/configure.php and includes/configure.php ) both have soulk_ in the DB_prefix line.

That maybe so, but the question remains, is this what they need to be?

Soulkreed:

If they are indeed the original local files and not the imported ones that have overwritten them.

Time to take a step or two back again.

I am/was under the impression that you had a working local installation and that you are now trying to import the database tables from your live server. If this is correct you shouldn't be importing any files at all (especially not the configure.php files) because these files will be different on your live host than they are on your localhost.

Soulkreed:

If they match the imported SQL database tables DB_prefix ( which they do from what i can see ) then it should work yes?

Yes, but only as long as the SERVER specification and file paths are also correct, and if you are overwriting your local copy of these files from the copy on your live server you WILL have problems, and things won't work as expected.

Soulkreed:

What I don't understand is if the SQL database files that I have imported in that have doubled up ( meaning the system doesn't know about them yet/can't put them where they need to be )

The doubling up of the database tables is telling us that your localhost installation is using a different table prefix than the server installation that did the export.

Soulkreed:

I am missing something here aren't I?
.

Yes

Cheers
Rod

Soulkreed:

I am looking at the SQL database backup table files in my text editor and it would appear that all of these files headings do not have soulk_ anywhere at all. This would suggest that I have been thinking that the imported files were the ones that had soulk_ before them but if I am correct it is the other way around.

This would also explain the doubling up.

Soulkreed:

If this is the case do i go through the SQL DB tables files and change everyone of them with my text editor one at a time to read soulk_

That'll be one way of doing it (and the way most likely to cause you to have problems and errors due to miskeying or mistyping).
A better way would be to use a search/replace tool.

The BEST way however would be to do what I have been trying to tell you all along, and that is to make your local installation match your live installation as closely as possible. If your live server uses 'zen_' as a prefix then when you create your local copy you should also use a 'zen_' prefix.
If your live server uses 'soulk_' as a prefix then when you create your local copy you should also use a 'soulk_' prefix.
If your live server doesn't use a prefix at all, then when you create your local copy you should also use no prefix.

By keeping the naming conventions consistent in this manner means that you'll not need to edit your .sql data file at all, and at the same time it also means one less difference to worry about between the configure.php files on the live server and your local server.

CHeers
Rod

Hi,
the SQL database tables backup files that I have imported are not from my live server, they are from my local backup save I did just before I transfered my files over to Dot Easy.
I know this probably doesn't change the fact that I still need to make the correct changes with the prefix's regardless weather the files are from my live server or my local ( I just thought i would clarify that for us, apologise for leaving that bit of info out )

Cheers.

Ok, it appears that the SQL database tables backup that I was importing doesn't have a prefix with it at all. I guess this is why it was doubling up so to speak. I re installed zencart this time without the table-prefix and I am now getting this when I import the files into the zencart database in phpmyadmin

MySQL said: Documentation
#1050 - Table 'address_book' already exists

Any clues please?

I have searched the threads about this particular error and am not making any head way, I think I'll give dropping each table a go one at a time and see if that does anything ( this is the long way I'm sure but I don't know what else to do here )

Here goes, gulp..

Well that proved to be quite a painful experience. I basically got more confused than I was before. It didn't work.
I give up..

Soulkreed:

I am now getting this when I import the files into the zencart database in phpmyadmin

MySQL said: Documentation
#1050 - Table 'address_book' already exists

Any clues please?

This is good. What you now need to do is DROP all of the existing tables (not the database itself) and then do the import.

Cheers
Rod

Soulkreed:

Hi,
the SQL database tables backup files that I have imported are not from my live server, they are from my local backup save I did just before I transfered my files over to Dot Easy.

Assuming there has been activity on your live server since your local save was made, the server database files will be more up to date than your presaved files.

Soulkreed:

I know this probably doesn't change the fact that I still need to make the correct changes with the prefix's regardless weather the files are from my live server or my local ( I just thought i would clarify that for us, apologise for leaving that bit of info out )

Cheers.

Correct, and this is why I've been recommending you make your local tables match what is being used on the server (assuming you were trying to re-create your server setup locally).

The fact that it now appears you are trying to recreate a local setup from sql backups made on an older local installation means that you'll be best using the same naming convention that was used on the original database. However, this will probably also mean you'll still have a naming mismatch between your newly restored local system, and the system used on your live server. Although having this mismatch isn't really going to 'hurt' anything, it WILL make it more difficult for you to export from one system and import into the other.

Cheers
Rod