Hi there,

I'm trying to upgrade our ICA-Atom instance to the latest 1.3 from SVN and
I've run into a snag which has me a bit perplexed, not being PHP-savvy. The
app itself seems to run okay until I try to log in, whereupon I get the
following error:

[wrapped: SQLSTATE[42S22]: Column not found: 1054 Unknown column
'user.ACTIVE' in 'field list']

Fair enough, there have obviously been some schema changes.

The I try and migrate the database using:

php symfony tools:upgrade-sql

This gives me the following error:

PHP Fatal error:  Class QubitTerm contains 4 abstract methods and must
therefore be declared abstract or implement the remaining methods
(ArrayAccess::offsetExists, ArrayAccess::offsetGet, ArrayAccess::offsetSet,
...) in /home/michaelb/dev/php/ehri-ica-atom/lib/model/QubitTerm.php on
line 30

I'm a bit perplexed as to why this happens, since none of the mentioned
files have been in any way modified, and the PHP version (PHP
5.3.10-1ubuntu3.4) isn't out of the ordinary. Does this error suggest
anything obvious that I may have missed?

Thanks in advance,
Mike

Hi Mike,

Please see an explanation and fix for this issue in our FAQ:
https://www.qubit-toolkit.org/wiki/FAQ#Why_do_I_get_a_.22Class_QubitA...

Regards,
David

--
David Juhasz
Director, Technical Services

Artefactual Systems Inc.
www.artefactual.com

Excellent, thanks David!

Hi David - sorry, I've hit another snag with this. Do you have any
suggestions for tackling the following error:

Error

*SQL query:*

ALTER TABLE<http://localhost/phpmyadmin/url.php?url=http%3A%2F%2Fdev.mysql.com%2F...>
 `information_object` CHANGE `identifier` `identifier` VARCHAR( 1024 )
CHARACTER SET utf8 COLLATE utf8_general_ci NULLDEFAULT NULL

*MySQL said: *[image: Documentation]<http://localhost/phpmyadmin/url.php?url=http%3A%2F%2Fdev.mysql.com%2F...>
#1071 - Specified key was too long; max key length is 767 bytes

I get this when migration 83 tries to change the size of
information_object.identifier and repository.identifier (which actually
have values in them.)  I have temporarily got the full migration to apply
by commenting out the changes to these tables, but obviously this isn't an
ideal solution.

Googling this error brings up a variety of apparent solutions related to
Mysql limits, but none seem to work in my case, even if I try to change the
values manually.  I'm using the Innodb engine (which was apparently the
default when the DB was created) and the utf8_general_cl encoding, with
MySQL 5.5.24-0ubuntu0.12.04.1 on Ubuntu.

Many thanks,
Mike

(And wow - the new theme looks fantastic - you guys have done a great job
with this version.)

Specified key was too long; max key length is 767 bytes

According to this post:
http://stackoverflow.com/questions/1814532/1071-specified-key-was-too-long-max-key-length-is-767-bytes

InnoDB only supports a maximum UNIQUE index prefix length 767 characters for InnoDB tables.

The default ICA-AtoM data schema does not include an index for the information_object.identifier or repository.identifier columns, have you added an index manually to your version of the software?

It looks like it should be possible to increase the column width by dropping the current index adding a prefix length to the unique constraint:

ALTER TABLE `information_object` DROP INDEX index_name;
ALTER TABLE `information_object` ADD UNIQUE ( identifier(767) );

Note you will need to substitute "index_name" with the name of the appropriate index in your database.



Regards,
David

-- 
David Juhasz
Director, Technical Services

Artefactual Systems Inc.
www.artefactual.com

P.S.  If the current column widths are working for you, then there is no
need to increase them.  We have had several users complain that the
title of their descriptions were being truncated, so we increased the
width of ALL of the text fields in the database to avoid similar
issues.  However, there is no need to increase the column widths if you
are not having problems with data being truncated.

--
David Juhasz
Director, Technical Services

Artefactual Systems Inc.
www.artefactual.com

Thanks again David - I think I'll just stick with the commenting-out
approach for now!