Recently, due to repeated "access denied" problems of my Drupal 4.x based site, I am in the process
of transferring the whole site content to a new drupal 5.x installation. This includes using 5.x version
of Biblio module within 5.7 Drupal. I am having problems importing biblio data from my 4.x based
site.
I do have a MySQL export .sql file that has the data for existing site Biblio module tables.
When I try to import the data in the MySQL database via phpMyAdmin to the new one,
I get an error that the number of fields do not match. Digging into the Biblio tables structures
I do see that 5.x version has several extra fields including vid after nid (node ID).
I am at a loss to know how to edit the MySQL exported data so that it imports into
the new Biblio module. Please advise.
Comments
Comment #1
rjerome commentedSounds like you installed the 5.x version of the module into a clean (new) installation of Drupal 5.x and are trying to import the data from a 4.x installation. Is that correct?
I believe the correct proceedure would be to point a 5.x installation at a set of 4.x tables and let the installation proceedure make the appropriate changes to the tables to bring them to the 5.x versions.
So I would do is setup a test environment, restore your 4.7 tables (all drupal tables including biblio tables), then point a fresh installation of drupal 5.7 at these tables and run update.php, then install biblio and rerun update.php and it should bring everything to the current verion.
Ron.
Comment #2
kalyana commentedDear Ron:
Yes, I want to use Biblio 5.1.13 module in Drupal 5.7 installation and be able to import data that corresponds
to Biblio 4.x module (data available as .sql file only, not in Endnote format)
Since the biblio tables of 4.x and 5.x do not have the same structure, I tried to import data directly to MySQL
by mentioning the target fields as in the following
INSERT INTO `biblio`(nid, biblio_type, biblio_number, biblio_other_number, biblio_secondary_title, biblio_tertiary_title, biblio_authors, biblio_secondary_authors, biblio_tertiary_authors, biblio_corp_author, biblio_other_author_affiliations, biblio_edition, biblio_publisher, biblio_place_published, biblio_year, biblio_volume, biblio_pages, biblio_date, biblio_isbn, biblio_lang, biblio_abst_e, biblio_abst_f, biblio_full_text, biblio_keywords, biblio_url, biblio_issue, biblio_type_of_work, biblio_accession_number, biblio_call_number, biblio_notes) VALUES (actual biblio data for the 30 fields mentioned)
But this did not work because there is another independent master node id table of Drupal elsewhere and
there were some duplication of node ids. Import fails due to duplicate entry/key fields errors.
In view of usage of same nid, vid fields in other Drupal tables, one need to sync. these tables as well.
Hence I figured out "importing mysql data" directly to the database should not be done at all.
I even messed up working of other modules when I managed to import few biblio sample data
due to conflict of node IDs.
If I understand you correctly, I should restore all Biblio tables of 4.x within Drupal 5.5, then install biblio
5.x module and run update to fix the structure of Bibllio 4.x tables. Wouldn't the installation of Biblio 5.x
and update process empty the content of existing MySQL tables of Biblio 4.x?
Another question: Is there anyway I can turn on the "export all Biblio data in Endnote format" by
editing any of the Biblio module related fields through phpMyAdmin. I can then use this Endnote
format data (instead of .sql data) to import the date into the new Biblio 5.1.13 module? My Drupal
4.x site is fully functional except that I cannot make any changes, see biblio listing at
http://solarcellsinfo.com/dyecell/biblio/
Kalyana
Comment #3
rjerome commentedAs you have discovered, since biblio type nodes are and extension of the basic drupal node type, for every biblio entry, there is a corresponding node entry, thus you can't just restore the biblio tables. And it is for this reason that restoring the 4.x tables into the 5.x install and running update.php won't work either.
You say you have a working 5.x site, and you say you are "in the process of transferring the whole site content to a new drupal 5.x installation". How are you doing this transfer? The normal upgrade path is to use the existing db tables and just install new php code. Have you created new db tables and manually transfered the content?
With regard to updating... Drupal has a "system" table, which contains details of which modules are installed and the current version of the database tables, this way when an new version of drupal or module is installed, it can look in this table to determine what changes are required to bring it's tables to the "current" state. For instance, if you look at the system table in your 4.x installation, you will probably see that the biblio module has a schema_version of 22. Now if you were to install a new version of the module in Drupal 5.x you would see that the schema_version is 26. If you had updated the 4.x tables to 5.x, when you activated the 5.x module the first time it would see that there are existing tables of schema version 22 and update them to version 26 and then all would be well. (Note: the schema version numbers are unrelated to the module version numbers)
In terms of exporting, I didn't see any export links on your site, but presumably they are available to privileged users. Your best bet would be to export all the entries in one (or all) of the formats and re-import that file into your new site. Probably EndNote "Tagged" format would be your best bet.
If you don't see the export links, go the the admin/access page and turn on "show export links" for the appropriate user.
Ron.
Comment #4
kalyana commentedDear Ron:
thanks a lot for your input. As i wrote earlier, main problem I have with my Drupal 4.7 version is
"access denied" problem at each stage. I cannot edit the content of my site anymore. So I could
not turn on "export links" option to export the data.
Anyway, I copy/pasted the displayed bibliography, edited the data to correspond to Endnote
and import the data to the newer Drupal 5.7 version-based site. It is a pity that, for a module
that stores data in MySQL cannot use the sql data to export to a newer version, except at the
very early (virigin) installation stage.
Kalyana
Comment #5
rjerome commentedHi Kalyana,
I'm sorry to hear that you had to go to all that trouble, and I wish you had contacted me again sooner since I'm sure we could have found a solution which would have avoided all that manual labor.
As for straight SQL data dumps, you have to remember that there are a couple of issues in play here. You were crossing version boundaries of both Durpal and the module and there is a tight interdependence between tables which has to be maintained in some fashion. The biblio data is not completely independent of the rest of the Drupal (node, taxonomy) data, but integrated with it, so what might seem like a simple problem on the surface often becomes quite complex when you start looking into the details.
This being said, I have crafted (in the 6.x version) a method of doing a complete backup and restore of the biblio data, although it would still require access to the Drupal admin pages.
Ron.
Comment #6
bekasu commentedMarking issue closed.