Warning and error has occurred suddenly started

[barco57]

normally when I see that error, it is a database problem. Run a repair on the database via phpmyadmin, suspect a table crashed during the outage the host had.

[RodG]

normally when I see that error, it is a database problem. Run a repair on the database via phpmyadmin, suspect a table crashed during the outage the host had.

This is pretty much exactly what I was going to say/suggest, especially after reading that the host were having problems with 'SharedDB servers'.

"occam's razor" dictates that the fault is most likely to be DB related rather than file related (in this instance).

Just my 2cents

Cheers
Rod

[DigiBooks]

I did all that. Repaired the tables (no error report).

Backed up the tables and put on the old site and all worked fine. Copied that and reloaded to the new site and it failed.

I even completely deleted the database .. created a fresh one and reloaded the tables but the problem persisted.

[RodG]

Run out of logic now!

I'll say. :)

Looks like I'm going to have to bite the bullet and go with the most recent backup and get 400 products reloaded!

Perhaps, perhaps not.

The problem I'm having/seeing at the moment is that some of your wording is a little unclear. You keep stating things like "made a backup and then...", which in itself is confusing. How many 'backups' do you now have? When you speak of 'backups' are you referring to the database(s), the files, or both?

Backed up from the old site to the new and it crashes. Reloaded a backup taken 10 days ago and it works.

So, in this instance, are you referring to the files or the database?

The fact that you *can* do whatever it is you are doing (old to new, new to old) and get a working site means that you also have a good means of narrowing the cause down to either the database *or* the files, and this is pretty much the 1st thing you need to determine if you have any hope of not having to reload a 10day old backup with the 400 products needed to be reloaded.

I'm still thinking its a DB related issue, so 1st, lets forget about "old site and new site' - Work *only* with the new site - and by this I mean the site with the newest *files*.

Now, I assume that you have at least *two* backups of the database files (possible even 3). One being from 10 days ago, another being a more recent backup.

If I'm reading you correctly, if you import the 10day old backup into what you call the 'new' site does it solve the problem? If yes, then it is pretty safe to assume the the *files* on this site are fine. The problem is with the newer database data.
I suggest that this be verified by importing the latest backup you have, which should, if a database issue, cause the problem to re-appear.

You should be able to repeat this affect as often as you like - keeping in mind that you won't be touching any *files*.

If this happens to be the case, then sadly, you will need to re-add those products (unless you have a newer intermediate backup that you can try)

If however, you import the 10day backup into what you call the 'new' site and it *doesn't* fix the issue then you can be pretty much assured that the problem is with the *files* and *not* the database. As before, you should be able to then reimport the newest backup, and there will be no change to the symptoms/problem. Again, demonstrating without a doubt that it is a file issue rather than a database issue. If this turns out to be the case, you're pretty much set - You can use the latest DB files, and you'll not have to worry about anything added or changed in the last 10 days. To invoke a cure from this position you should only need to replace the *files* on what you call the 'new' site with the files (that you now know are fine) from the 'old' site.

Does this make sense?

If not, look at it this way.
You have two sets of *files* (call them set 'fA' and set f'B')
You also have two sets of databases (call the dbA and dbB)

(if it helps, consider 'A' as the 'new' site, and 'B' as the 'old' site).

There are now 4 combinations:
fA & dbA
fA & dbB
fB & dbA
fB & dbB

You have already determined
fA & dbA = busted
fB & dbB = working

You now need to determine the results of using
fA & dbB
fB & dbA

If
fA & dbB is busted - You have a problem with fA
fB & dbA is busted - You have a problem with dbA

If the problem is with dbA, then you have no choice than to use the older DB files (dbB) (fA files are fine)
if the problem is with fA then you have no choice other than to use the files found in fB (dbA is fine)

Does it make sense now?

Bottom line is that you need to determine whether it is a file or DB issue.

I'm sure that you have, along the line, already tried all 4 combinations - but what you haven't done is understood the reason you are getting the different results, nor have you provided us with the results of these combinations in an unambiguous manner, which is partly (mainly) because you haven't been very consistant with what you are actually referring to when you say you did a 'backup' which could be the files, the database, or perhaps *both* at the same time - and this latter is going to cause no end of confusion. Until/unless this ambiguity is cleared up we could easily be led astray and come to an incorrect conclusion.

Cheers
RodG

[DigiBooks]

Hi and thanks for a very comprehensive explanation. All was going well until we hit 17,400 books online again today (around 5,660 categories). I am struggling to see what is going wrong though I understand that I need to determine whether the files (category images, book covers, download zip files, author images) are the contrinbuting factor.

Again loading the database back to the original server and site works fine (but that is loading the database and not all the corresponding files so I need to investigate those further).

Just one question for now .. is there a limitation on what Zen-Cart can handle in these searches that could be causing the advanced search to crash> Smple search on selected text continues to work fine but I have seen from the page source codes that a lot of data is called an loaded to the script before you even start to enter the criteria you wish to narrow the search down to.

Thanks again

[RodG]

Again loading the database back to the original server and site works fine (but that is loading the database and not all the corresponding files so I need to investigate those further).

Still trying to be sure we're on the same page (it helps if you treat me like an idiot)

"The database" = being the one with the latest data? True/false

"original server" = The server that works fine with both this 'latest' data *and* its original/older data. True/False?

If both answers = 'true' then you have a problem relating with the *files* on the 'new' server. It is NOT a database issue.

If either answer is false, then we are on different pages and it could still be a database issue.

Just one question for now .. is there a limitation on what Zen-Cart can handle in these searches that could be causing the advanced search to crash>

Simple answer. No.
Less simple answer - Could be that you are running out of memory with this many products.

More accurate answer, in the form of a question - If you are loading the latest DB (the one with the most products) into the old server, and the old server doesn't have an issue with this DB of products, then what logic would dictate that the issue could be related to the number of products (as the same number would now be on both the old and the new server)?

IOW, if you answered 'True' to both of the questions above then you have already eliminated the number of products as being relevant.

Smple search on selected text continues to work fine but I have seen from the page source codes that a lot of data is called an loaded to the script before you even start to enter the criteria you wish to narrow the search down to.

I'm not sure what you are quite getting at here, but if it is telling us anything useful at all, it is that assuming both my initial statements are 'true' (which means a file related issue on the new server) then this observation has narrowed it down to something specifically dealing with the files associated with the advanced search, and that any files that are common to both the advanced and simple search are probably OK.

IOW, we now know the cause is related to just one or two files on the new server. That is of course, if my current assumptions are true and I've not misunderstood anything you've stated.

Cheers
RodG

[RodG]

I've just thought of one other thing that could blow my current logic/diagnosis out of the water.

Assuming that you are correct and the the issue is caused due to the number of products. Also assuming that this same number of products (DB) is on both the old and the new servers, it is theoretically possible (although *probably* unlikely) that the 'new' server has less resources available to it than the old server - with the old server able to cope with the number of products and advanced search, but the new server being under-powered.

IOW, it could be neither a file or a DB issue, but simply an underpowered 'new' server.

I'm making a lot of assumptions here though. I hate making assumptions.

Cheers
Rod

[DigiBooks]

Hi RodG

Sorry I haven’t maybe been using the right terms to describe the issue. So before I plough into carrying out extensive tests I will try to clarify thiings.

My reference "The database" is the MySQL tables which the contain all the data used to drive the system – so in our case I am looking specifically at:
manufacturers (authors) and categories – our categories have three levels (genres at top-level, authors within a particular genre beneath that and book series (product groups) beneath that – but all contained in the categories table.

Of course as you already know there are many more –but at the point where the search crashes I don’t believe that these are yet relevant because the advanced search crashes before we it has completely loaded the form on screen.

My interpretation of ‘files’ are those that are stored in folders on the server to which the data in the ‘database’ makes reference and pulls the files through to build the output pages (in our case we have 4 main folders:

Images/authors
Images/category images
Images/book covers
Book zips  the downloadable files which are displayed as links in the final checkout page (all our products are virtual.

Here is my reasoning why the problem either exists in the ‘database’ or, of course potentially, a memory issue on the server:

To display the form in Advanced Search Zen-Cart appears to build three lists:

Top-level categories (Genres)
Sub-categories (Author within genre and series within author within genre)
The latter two are used to create the drop-down lists that a customer may use to refine the final search.

At this point the ‘files’ haven’t been interrogated by the program (my understanding is that they will only be accessed once the customer has refined the final search criteria?)

We currently have two servers with our host Web122 (the latest site) and Web60 (the older original site) both running V1.5.1 with different layouts.
So, at some point Web122 gets to the stage where it displays the keywords field section in Advanced Search but stops at Limit to Genre (Limit to Category); the last with the PHP warning message, this time just stops with no message. Viewing the webpage source shows that it has loaded the top-level category list but falls over before it can display the first drop-down list – that data has not been loaded.

If I take a copy of the ‘database’ and reload it to Web60 then Advanced Search completes the form correctly. The fact that I haven’t loaded all the relevant ‘files’ to that server I think is irrelevant because the worst that can happen (and I have tried this) is that the newest data returns the book but without a book cover image because that doesn’t exist on this server (and of course if you progressed that through the checkout process then it would fail to provide a download link for these books.

I think that this test alone proves that the ‘database’ is good and that there must be some server issue in the background that is causing the crash (it does say that maximum DB size per database is 500Mb – we are currently using 50Mb).

I have sent an email to my senior manager contact at the host to check it out the shared DB’s on Web122 because as far as I can see our ‘database’ is fine. I’ve also asked the question regarding memory limitations – is something different set up on Web122 to that on Web60?

I hope that explains my simple ‘logical’ way of working through this and will let you know what the host comes back with.
Thanks

[DigiBooks]

I've just thought of one other thing that could blow my current logic/diagnosis out of the water.

Assuming that you are correct and the the issue is caused due to the number of products. Also assuming that this same number of products (DB) is on both the old and the new servers, it is theoretically possible (although *probably* unlikely) that the 'new' server has less resources available to it than the old server - with the old server able to cope with the number of products and advanced search, but the new server being under-powered.


The hosts say that all their platforms/MySQl run the same resources but they have asked the server engineers to look into the issue. They will have a soft launch of their new datacenter/platform in early Feb and are offereing me trials o
IOW, it could be neither a file or a DB issue, but simply an underpowered 'new' server.

I'm making a lot of assumptions here though. I hate making assumptions.

Cheers
Rod

Hi The hosts say that all their platforms/ MSQL are the same on all servers but they have advised the engineers to look into it. They are also making a soft lauinch of new servers/datacenter in February and will allow me to trial these out. I still think the problem lies with the datacenter right now

[DigiBooks]

I am going to run a trial by putting a clean version of Zen-Cart into a new folder linking it to the existing database that is crashing and the image/zip folders. If that all works on the new server then it's conceivable that I have screwed something in the reprogramming that I'm not aware of even though I would not have touched the search scripts. Thinking now I did load a new Admin Console template and made some alterations there. It could be my fault entirely :/