1. Forum
  3. Joomla
  5. Issue Tracker
  7. Error when restoring with Softaculous

Error when restoring with Softaculous

8 years 4 months ago #1 by cosmin
Error when restoring with Softaculous was created by cosmin
Hi there

I`ve install on a J!3.4.5 Issuetracker_1_6_9. From what I can recall there was some sort of an error when installing ( can not tell exactly what it was ) but I went ahead and the component seamed to work . I use Softaculous as a backup utility. At the moment I need to revert at a previous version. The first time I`ve tried there was an error in regard to a View. I deleted the databasa all togever and now I keep getting the error

The following errors were found :
Table 'netdent_efex.akemg_it_project_view1' doesn't exist


Maybe this is related: I`ve tried to install the component on a sub domain ( different DB prefix ). I get the error

Table 'netdent_joom792.jos9i_it_issues' doesn't exist SQL=ALTER TABLE `jos9i_it_issues` ADD issue_type int(11) DEFAULT '1' NOT NULL COMMENT 'Type of issue. i.e. defect etc.' AFTER assigned_to_person_id, ADD CONSTRAINT `jos9i_it_issues_type_fk` FOREIGN KEY (issue_type) REFERENCES `jos9i_it_types` (id) ON UPDATE RESTRICT ON DELETE RESTRICT;


It would be great if I could restore the instance of he main domain.

I do not know much about DB in general ... . :(

Thank you very much for your time.

Rgds
Cosmin

Please Log in or Create an account to join the conversation.

8 years 4 months ago - 8 years 3 months ago #2 by geoffc
Replied by geoffc on topic Error when restoring with Softaculous
Welcome to the world of database problems. We do not have any experience of using Softaculous but there are some general rules which I am sure will aid in resolving the problem.

First a view is a specific database object, which can be thought of as a 'window' upon the underlying data held in one or more database tables. As a database object the database controls who can and cannot create database views. If may be that upon the source database you had permission to create views but on the destination database this database privilege has not been granted. This is probably unlikely but a possibility. Alternatively it may be that the backup software has not be configured to include views in the backup file, hence when the restore takes place the views are not restored. We would expect most backup software to have a specific configuration option to control what goes into the backup, if it does not include them by default. Similarly there would be options to control the backup of database procedures and functions etc.

Issue Tracker uses a couple of views, mainly to improve performance but upon an install it checks whether the site can create database views and if so it creates the views, otherwise it uses a (much more) complex database query to get information in the search queries. This is why the initial install would work correctly and what you probably missed was the informative messages(s) letting you know what the installer was doing.

There are if I recall only two views in use which you could check in the database if they exist using myPHPAdmin (or something equivalent) and if they do not exist recreate them, assuming you have the database permissions to create them.
CREATE VIEW `#__it_project_view1` AS 
         SELECT B.id, B.parent_id AS pid, C.level, C.title, C.access 
         FROM `#__it_projects` AS B, `#__it_projects` AS C 
         WHERE (B.lft BETWEEN C.lft AND C.rgt) 
         AND C.level != 0 
         ORDER BY B.lft, C.lft 
         
         CREATE VIEW `#__it_project_view2` AS 
         SELECT id, GROUP_CONCAT(title ORDER BY level ASC SEPARATOR ' - ') AS title, access
         FROM `#__it_project_view1` GROUP BY id

Change the database prefix as appropriate for your site. You can see the code for these views in the script.php file around lines 740 to 760.

Views themselves do not contain any data, only the instructions of how to access the data held in the tables to which they refer.

(Aside: Without knowing specific details of the database prefixes of the source and destination databases, it might be worth checking the database prefixes used in the views. Possibly the backup software has not modified the references tables in the database view itself and is referring to the old database suffix? This might indicate a backup software restore bug? Dropping and recreating the views would correct this if it is the cause of the problem. It is perfectly correct practise to refer to different database prefixes in views as a means of cross database references, but in our case this is not the purpose of the views.)

Another alternative might be to 'reinstall' on top of the restored database the current release. This is safe to do, although you might want to test it first yourself, and we use it regularly in our development testing. It tests whether database objects (tables, views etc) already exist before trying to create them. In the case of the required views, we first drop them before recreating them.

These should resolve the view not existing messages.

Your second problem (which is not a database restore problem) sounds like a previous attempt to install the component on the existing system failed, for some reason and that another install attempt is being tried. The subsequent install is picking up the 'relics' of the first attempt and hence failing. The issues table is one of the early tables installed and the 'ALTER TABLE' which is an update change seems to indicate that it thinks an 'earlier' version exists. Possibly a much older installation?

It is not related to whether it is a sub domain or not, as we use sub domains frequently and do not see any problems.

In our FAQ there is an entry that goes into more detail about how to remove any traces of a previous installation which I will not repeat here. If the database tables have already been removed I suspect it will be some 'old' entries in the #__extensions table left behind.

You certainly should be able to restore to a different domain.sub-domain as we do so regularly, although as we mentioned at the beginning we do not have any experience of Softaculous instead using Akeeba Backup ourselves, a personal choice, although I do not currently think that the backup software is fault here.
Regards
Geoff

Please Log in or Create an account to join the conversation.

  1. Forum
  3. Joomla
  5. Issue Tracker
  7. Error when restoring with Softaculous
Time to create page: 0.147 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries