I receive the following error in my self hosted control panel (Screens/Actions -> Add New) SELECT P.guid, P.uniquePluginId, P.displayAs, P.category, P.webDirectoryName, P.versionString, P.shortDescription, (SELECT Count(id) AS count FROM bt_items AS I WHERE I.uniquePluginId = P.uniquePluginId AND I.appGuid = 'EA6BB9F9CF89F1359F0116D8C' ) AS countOfScreens FROM bt_plugins AS P LEFT JOIN bt_items AS I ON P.uniquePluginId = I.uniquePluginId GROUP BY P.uniquePluginId ORDER BY countOfScreens DESC ________________________________________ Database Error! Error #:1317 Error: Query execution was interrupted It seems that the bt_screen.php query get interrupted or times out. I checked with my hosting company (Pow Web) and the query time out limit is 60 seconds but I am not sure if that is the issue or if anyone else has seen this issue on their self hosted control panel. I have a lot of records in my bt_items table (11k but from a database record perspective that is not a lot of data. Any ideas or suggestions anyone?

Hi...Have never seen this message before. 11K records is nowhere near enough to "slow down" an average mySQL database server. Do you know what kind of machine this is on? Do you know how many other folks are using the machine (is it shared hosting?). There are no scripts in the package that should take more than a second or two to load. If they do, you've got a very very slow machine on your hands. You could try to review the server's variables using PHP. Literally hundreds of things can 'slow down' a machine but I don't think it's that query. I'm running a self hosted package on a test machine (a modest machine with very little memory) that has literally hundreds of thousands of rows in most of the tables. The whole point is to hammer it to see where it slows down. No slow yet. Maybe it's a shared hosting thing? Wish I could offer more.

Thanks for the reply David, I did play around with the php.ini file a bit on my hosting account to see if that would change things and it did enhance the performance a bit so now the issue is random and only happening on applications that have a lot of screens. It is a shared server so I definitely believe it has to do with a slow server or a time out. Does this error give you any other clues? An error ocurred in the fnDbGetResult() method in utilityFunctions.php (4)

Good to hear. The fnDbGetResult() method is just the codes way (I wrote all this) of showing you what method failed. In this case, the method that is "connecting" to the database and "executing" the script is in the utilityFunctions.php file. It does sound like the server could be beefed up a bit. Another thing I thought about after posting last night was the idea of creating, adjusting, or removing some of the table indexes in the database. If you're unsure what this means, it may be out of your reach. But, if you have some understanding of how mySQL is optimized, you may get some serious mileage out of making sure the indexes on the related tables (related to this one query) are tuned. Dunno. Happy apping...

Definitely not an expert on mysql but there is always google.com I will play around with it and see what I can come up with....short term it might be OK but long term I need to find other alternatives....any recommendations?

Modyfying indexes improved the timeout significantly however the error still happens fairly often so I definitely will be moving to a new dedicated server.

Hi guys, After David's suggestion fo turning ON error reporting, I received the error: "the table bt_items is marked as crashed and should be repaired" I ran (without qoutes): "REPAIR TABLE mytablename_items;" in a SQL in PHPMYADMIN and it solved the: fnExecuteNonQuery() method in utilityFunctions.php (6) error. Thank you David! Hope this helps others. David https://buzztouchmods.com

@MrDavid: Cool. BUT, how and the heck did your BT_items table crash. I have no idea what backend you're on these days but could it be that nobody is doing any "check_table" routines on a regular basis? I ask this because check_tables is a critical part of normal maintenance and routine for mySQL DB admin's. Naturally there are a ga-zillion ways to handle this. IE: Cron jobs, monkeys tapping refresh twice a day, etc, etc. The idea is that some sort of script or program should be checking your database's integrity on a regular basis and acting accordingly before things get bad. I generally use a .php script that does all sorts of checking on all sorts of things (like databases, files systems, memory usage, etc) then roll up this info into an email. The automated routine sends it to me so I can review it. If things don't look well (check_table helps us see that in advance) I go to work to isolate and fix stuff before the crash and burn. LOL Database tables are sort of like Hard Disc's in that they tend to get fragmented and unorganized over time as records are added, removed, updated, etc. This is not a BT things, it's a standard database thing. Remember the old disc de-frag days, repair_table does the same thing. It's like mySQL's way to clean things up. My suspicion is that the database server that's running this database is generally neglected until things don't work. This is pretty normal. Bogus but normal for sure. "If it ain't broke don't fix it" is SOP (standard operating procedure) for tons and tons of folks. We have lots of catching up to do!!!

@David I'm actually using Hostgator, this is the first time it's happened in years of using them so I'm going to let this one go, lol! I would like to think hostgator is above SOP but you never know. As for BT_Items crashing, I only have 2 theories: 1, my API requests table was off the hook huge, like ridiculously huge, perhaps that overloaded something? or 2, Sam and I were working on the same app in the same control panel, perhaps we did something that conflicted and crashed an item? Who knows! We do! But I know you are crazy busy, so no rush and no worries. Thanks David, David