Error at Step 8 - Unable to install the core module Unable to activate the core module

Hi

After solving the MSSQL problem by using a nightly snapshot, I'm now having problems with Step 8 of the installer.

I get the following error. I've checked the common problems and this forum. I've deleted everything and started againa couple of times, but it fails at the same place everytime.

Unable to install the core module
Unable to activate the core module

I've attached the log as requested.

I hope someone can help!

cheers

James

Gallery version (not just "2"): nightly snapshot from friday
PHP version (e.g. 4.3.11): 5.1.6
PHPInfo Link (see FAQ): N/a
Webserver (e.g. Apache 1.3.33): IIS 6
Database (e.g. MySql 4.0.11): MSSQL
Activated toolkits (e.g. NetPbm, GD): GD
Operating system (e.g. Linux): Windows 2003 server
Browser (e.g. Firefox 1.0): Firefox 1.5.7 and IE 6

You know, I don't know - let me find out...

In your log I can see:

Apparently there is an SQL syntax problem. Something must have changed recently, because this did
work.

I'll look into it today and keep you posted.

Thanks for letting us know.

BTW, a word of advice... forgive me if it's obvious. Nightly builds are great for testing, but
do NOT build a production server using it. Only use GA builds for production servers. I am not a
stupid person, but I did exactly that. Then after about a year of happiness I hit problems with it,
and I found it was impossible to migrate to a GA (supported) build
(http://gallery.menalto.com/node/52902). I spent about 2 weeks trying to find a way to migrate it, then
I just gave up and reinstalled my server from scratch.

Hmm, it still is working fine for me. That exact same statement runs successfully.

My version of SQL Server is "SQL Server 2005 Express Edition". I don't know how your "Enterprise Edition
Version 8" compares to that. Assuming you SQL Server is older than mine, I'll still try to find a
solution that works... I'd like to have Gallery support as many versions of the DB as possible.

So the question I now have is: Is the problem the "(MAX)" or the "NULL"?

A simple test case is:

C:\MyServer>sqlcmd -S cs288290-a\SQLEXPRESS -d gallery2 -U myuserid -P mypwd -e
1> create table testtbl (col1 nvarchar(max) NULL)
2> insert into testtbl (col1) values ('Test string')
3> insert into testtbl (col1) values (NULL)
4> select * from testtbl
5> go
create table testtbl (col1 nvarchar(max) NULL)
insert into testtbl (col1) values ('Test string')
insert into testtbl (col1) values (NULL)
select * from testtbl


(1 rows affected)

(1 rows affected)
col1



--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------
Test string



NULL




(2 rows affected)
1>

Can you do that on your system? If not, try changing "(MAX)" to "(32") and try again. Then just omit
the "NULL" and try again.

Thankyou very much for trying to help - I will try this tmw when I get into work. I don't have cmd line access to the server, so I will knock up a PHP script to do the above and post the output.

I have a fair bit of runway in the project - it is non-essential, so I will probably hold off on live until that release. I still want to install this nightly though so I can have a play around with all the features, and decide what will and won't be installed and/or asseciable when it goes live!

again, thanks for your help, speak to you tmw.

J

Thanks Valiant.

I'm leaning toward simply not using "NVARCHAR(MAX)", just to keep it simple. Would "NVARCHAR(4000)" be
acceptable? (4000 is apparently the max size for NVARCHAR. In DB2 we use "CLOB(2G)", but I don't see an
equivalent for LOBs in the SQL Server doc. In 'lib/tools/bin/generate-sql.php', column definition
'TEXT-SMALL' is already "NVARCHAR(4000)".)

I considered changing it to "NTEXT" until I saw:

If you prefer to add a version check, it looks like there's a "@@VERSION" that I might be able to use.
(Function getVersion() currently simply returns an empty string.)

Edit: But then, will that version checking actually be of any use at SQL-generation time? (This is not a User task.)

OK, I have an updated "generate-sql.php" that should fix this problem. The install still works for me,
and I've confirmed that the troublesome column is now NVARCHAR(4000).

I'd like to checkin this change into SVN, but I'm not sure if I also have to checkin any updated
"schema.tpl" files, and if so, which ones.

Valiant, can you clarify that for me?

Lovely!

Now, after an hour of messing arounf this morning I have a working install!

I had a couple of problems, which you probably want to know about. They were all related to a "maximum row size" of 8051. So a few of the tables with "NVARCHAR(4000)" in them triggered this error. I changed all fo them to "NVARCHAR(3500)" which got rid of most of them, but in g2_Item, I had to change it to "VARCHAR(2900)".

I'm not sure what affect this will have on the running of the system, I'm sure I will find out soon enough!

Also, I wasn;t able to install the Comments modules for the same reason (I haven't changed that yet though), but I didn't check each module.

If you do want to support this database version, I will be happy to test any code you are thinking of releasing. It might be a bit too much trouble than it's worth though!

J

No worries.

I can't capture the error as I can't actually log into my nice new gallery! Even as the admin. I get a blank page after I enter the password. I'm sure this has something to do with something I changed, but unfortuantly I don't have time to play with it at the moment

However, the error was with this SQL statement:

# GalleryComment
CREATE TABLE DB_TABLE_PREFIXComment(
 DB_COLUMN_PREFIXid INT NOT NULL,
 DB_COLUMN_PREFIXcommenterId INT NOT NULL,
 DB_COLUMN_PREFIXhost NVARCHAR(128) NOT NULL,
 DB_COLUMN_PREFIXsubject NVARCHAR(128) NULL,
 DB_COLUMN_PREFIXcomment NVARCHAR(4000) NULL,
 DB_COLUMN_PREFIXdate INT NOT NULL
);

Which has the "NVARCHAR(4000)" statement in it.

To me, a ~8000 limit on a row seems a little restrictive!

cheers, I'll have a look into that in the morning!

Also, I'm assuming that you did not rebuild the 'schema.tpl' by running 'gmake', but just updated
'schema.tpl' directly.

Could you tell me exactly which SQL statements you had to change, and what values you used in each
one? I need to know this in order to finalize the 'generate-sql.php' changes for this support.
Perhaps just attach your 'schema.tpl' and I'll diff it with mine.

I just finished typing up a response to this (took about half an hour) then when I hit "Submit"
GMC f-ed up and lost my posting. Now I can't retrieve it, I have to re-enter the response.
This forum software really pisses me off, especially when combined with GMC's finnickiness.

OK, Take 2...

Thanks PG.

I can see by your file that you changed:

G2_SessionMap.G_data from 4000 to 3500
G2_Item.G_description from 4000 to 3500
G2_PluginParameterMap.G_parameterValueTemp from 4000 to 3500
G2_PluginParameterMap.G_parameterValue from 4000 to 3500
G2_CacheMap.G_value from 4000 to 3500
G2_MaintenanceMap.G_details from 4000 to 3500

But then you say you changed G2_Item.G_description to 2900. Which is correct?

Valiant:

Based on the above, it seems that the largest value we can specify for 'TEXT-*' fields
is 2900. Is that big enough to be practical?

Since SQL generation is not done at runtime, we cannot determine the SQL to use
simply by querying the version of the database, unless we create a whole second set of
SQL for pre-2005, which sounds like a lot of work & code bloat.

So I see three alternatives:

1. Make all 'TEXT-*' fields 2900 for all versions of SQL Server.
2. Create another complete set of SQL statements for pre-2005 versions of SQL Server.
3. Simply don't support pre-2005 versions of SQL Server.

Unless you have any more options, I'm OK with option 1.

Purplegecko,

We discussed this in the gallery-devel mailing list, and the general consensus was that the limitations
of pre-2005 versions of MSSQL make them too likely to cause problems with certain internal functionality
of G2, so as a result, Gallery will not be made to support 'pre-2005' versions of SQL Server.

I'll be updating the Gallery2 MSSQL doc momentarily.

Sorry we couldn't make it fly. If a way around these 8k limitations is found in the future I'll be
happy to reconsider it at that time.

Thanks for your help in investigating this; it was a learning experience.

I too just tried to install Gallery2 under IIS and MS SQL server 7.0 and ran into the MAX problem. But, I'm a DBA and have been working with SQL server for a while. My question to the programmers of Gallery is, when you are trying to create an NVARCHAR(MAX) field, what is your real goal? How many characters are you trying to store in this field?

I ask for two reasons;

1) The NVARCHAR type is used to store UNICODE text, thus cutting in half the available space of a normal VARCHAR type. For MSSQL as far back as 7.0, if you use VARCHAR(8000) as the upper limit where the max of NVARCHAR is NVARCHAR(4000).

2) If the purpose is to store a LOT of text, then you should use the TEXT type. The upper limit for this field is 2GB for TEXT and 1GB for NTEXT (unicode version). When retrieving text from a Select *, the default returned is 4096 bytes but can easily be set to the full 2GB in the database via the "SET TEXTSIZE 2000000000" command the same way you are creating the tables in the setup script.

Not everyone can afford to upgrade to SQL 2005 and there are plenty of 2000 and 7.0 servers still running.

Hope this info helps you support use 7.0 users.

Cheers!

john

Disclaimer: Bear in mind that I was not the original author of the MS SQL Server support in G2. When I
volunteered to pick up the ball and run with it, I had no previous experience with SQL Server.

The original author chose to use NVARCHAR(MAX). I don't know his exact reasons for doing so, but
I would probably have done the same thing, based on the following Microsoft documentation:

• http://msdn2.microsoft.com/en-us/library/ms187993.aspx (See the "Important:" note warning us to not
  use *TEXT types because they are being deprecated in favour of *VARCHAR(MAX).)
• http://msdn2.microsoft.com/en-us/library/ms186939.aspx (The maximum non-"MAX" size that can be
  specified for NVARCHAR is 4000... nowhere near the 65000 that G2 looks for. I did try using
  NVARCHAR(4000), and, as Valiant predicted, I ran into major problems with G2's session data
  almost immediately.)

We discussed this in the gallery-devel list, and one of the options discussed was having a separate
set of SQL for pre-2005 versions of SQL Server (it can't be a run-time decision because the SQL is
generated long before the User even downloads G2).

However, IIRC, Mindless said that there is a way to make the SQL somewhat more dynamic at
run-time (at least in terms of datatype). So perhaps we could do that, I'd love to see G2
support pre-2005 versions of SQL Server, but...

• I've just started a new job so I don't have much time to devote to G2.
• I don't have pre-2005 versions of SQL Server on which to test it.

As for not being able to afford SQL Server 2005: the Express edition is free.
I will grant you though that there could be other reasons why existing pre-2005 installations can't
upgrade to 2005.

That sounds pretty simple... (or is Valiant simply a good salesman? )

The getVersion() function in MsSqlStorage.class is currently empty (just returns ''). I'd guess that
it should probably look something like this:

	list ($ret, $tmpDb) = $this->_getConnection(true);
	if ($ret) {
	    return $ret;
	}

	$sql = "SELECT @@VERSION";
	$arr =& GetArray($sql);

	if (empty($recordSet)) {
	    return GalleryCoreApi::error(ERROR_STORAGE_FAILURE);
	} else {
	    $tmpDb->Close();
	    return implode("\n", "$arr");
	}

Here's the version info returned from @@VERSION on my SQL Server 2005.

select @@VERSION

-----------------------------------------------------------
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86)
        Oct 14 2005 00:33:37
        Copyright (c) 1988-2005 Microsoft Corporation
        Express Edition on Windows NT 5.1 (Build 2600: Service Pack 2)



(1 rows affected)

I don't know what is returned by pre-2005 versions. John.friel says he's on version 7, and purplegecko
said he was on version 8.

We'd probably need to decide what minimum release G2 will support.

Folks (john.friel and purplegecko)...

I've just finished coding up support for pre-2005 versions of SQL Server. I'm just waiting for the
code to be reviewed and for the go-ahead to commit the changes for Gallery 2.2.

I've tested it on my 2005 server, and I hacked it to think that my 2005 server was V7, and it seemed
to work fine, but I don't have an actual V7 or V8 server to test it. If somebody out there has
access to V7 and/or V8, I'd really appreciate it if you could run at least a sanity check when
it is committed into the build.

If it goes in and the Unit Tests run well, you can buy me a beer next time you're in Toronto.

Hello,
Sorry for pumping up such old topic, but I have some thoughts on compatibility with older versions of MSSQL (such as MSSQL 2000).
I'm posting here because this topic covers some implementations of MSSQL 2000 support, and I have the further suggestions.

First of all, as note for Gallery developers, the free version of MSSQL 2000, called MSDE (equivalent to MSSQL 2005 Express Edition) is still available at:
http://www.microsoft.com/sql/prodinfo/previousversions/msde/download.mspx
You may also download the latest service pack (SP4):
http://download.microsoft.com/download/1/B/D/1BDF5B78-584E-4DE0-B36F-C44E06B0D2A3/ReadmeSql2k32desksp4.htm
https://www.microsoft.com/downloads/details.aspx?familyid=8E2DFC8D-C20E-4446-99A9-B7F0213F8BC5&displaylang=en

Unfortunately, I have no time to audit every file in Gallery's source code, but I have some suggestions related to well known incompatibility of linked item module. Probably, my notes will help in other areas.
The issue, for example, is described in the following forum post:
http://gallery.menalto.com/node/67929

After reviewing the linkitem module, I have found some problems, listed below:
1) There is a flaw in database design. The [GalleryLinkItem] table (g_linkitem?) has the 'g_link' field, which holds semantically incompatible values (the album id, which is int, and remote pic uri, which is string). This breaks basic theoretical requirement of uniformity of data stored in the column. It may be acceptable if this field is treated in some generic way, like some abstract freetext value. But this field is used as a key, because it is searched in database queries. From database architecture side of view it is simply wrong.
2) For the MSSQL, there is no need for this field (g_link) to be "text" (or ntext, or nvarchar(max)) at all. There is well known limit for url size, imposed by MSIE. Internet Explorer limits the acceptable size of URL to 2083 characters. Also, Apache (the most popular webserver) will not accept URL longer than 8000+something bytes long, responding with 413-Entity-too-large error. Therefore, it can be assumed that every accessible URL in the world fits into 2083 characters, because MSIE is still dominating browser.

Sources:
http://support.microsoft.com/kb/208427
http://www.boutell.com/newfaq/misc/urllength.html

3) I'm not sure that there is the reason for 'g_link' field of that linkitem's table to be unicode. The http headers is actually is 7-bit media for historical reasons, so everything, including URLs are typically somehow encoded to 7-bit values. Yes, some servers accept 8-bits and more, but generally it is unsafe.
The URI paths are generally either urlencoded (7-bit value), the parameters are encoded too. Even with increasing popularity of International Domain Names (IDN) containing unicode symbols, they are "punicoded" behind the scenes into 7-bit values. So, why don't store them as 7-bit data? Or your remote thumbnail generator supports IDN?

Summarizing everything, the MSSQL scheme for 'g_linkitem' table may store remote pic URL as simple varchar(2083) instead of ntext or nvarchar(max).

Being constructive, I have the following solution for this MSSQL incompatibility (and probably others).

The linkitem/module.inc line 170.

There is a query, which searches items to be deleted. MSSQL fails to delete this field because [GalleryLinkItem::link] (or 'g_link') is being directly compared/filtered with the output of $entity->getId(). MSSQL fails this because it can not compare 'text'-typed columns. However, the 'text' and 'ntext'-typed column are still perfectly LIKEable. The LIKE construct, if used without wildcard, means "exact" comparizon, that it what we need, right? And this behaviour is cross-database, at least MSSQL and MySQL behave identically, returning exact match using existing indexes.
So, the above-mentioned SQL query could be rewritten to:

The '?' is in quotation marks, because of type-casting array((string)$entity->getId()).
If the pattern of using 'text' (mysql) and 'ntext'/'nvarchar' (mssql) values for exact comparizons is used somethere else in Gallery's code, this approach could help.