CMSMadeSimple With MSSQL

[madelyn]

Hello:
I'm trying to install cms with mssql, because cms supports adodblite.    But install fails.    I am using cmsmadesimple-1.0.4 and adodb_lite1.42.

Thanks for your collaboration

[Dee]

Hi, currently CMS Made Simple only supports MySQL and Postgres databases.
There is no option to use a MS SQL database during install.

What do you mean install fails? How did you try to install on MS SQL? Did you modify the install to be able to select mssql?

Regards,
D

[madelyn]

Yes I modified install.php, but the dump file is not compatible with mssql.

Any Idea?

[Dee]

I never used MS SQL, so no idea. What errors do you get?
BTW: someone else is also trying to get CMS Made simple to work with MS SQL: http://forum.cmsmadesimple.org/index.ph ... 827.0.html

[madelyn]

Hello:

I had been installed cmsms with mssql:

* First I did it in mysql
* Second I exported the data base to mssql.

After solved all the small problems, still have one problem:

The default page shows error 404, but only works  with direct link.

What could be the error?

I Use adodb and IIS.

Madelyn

[Dee]

The default page shows error 404, but only works  with direct link.

What could be the error?

I Use adodb and IIS.

Madelyn

Is it a IIS 404 error or the one generated from CMS (Site Admin -> Global Settings in the admin menu)?
IIS is configured to use index.php as directory index?
Any PHP errors (check apache access/PHP error log)?

Regards,
D

[madelyn]

Hello:

No.  It's Shows  cmsms  page 404 error.

index.php is the primary document in IIS.

Madelyn

[Dee]

No.  It's Shows  cmsms  page 404 error.
Madelyn

Hmm, I assume you made sure "Enable Custom 404 Message" is unchecked in the Global Settings?

It's hard to tell what goes wrong without any further debugging info.
There's a couple of things you can check to find out what's going on:
* CMS: set $config['debug'] in config.php and check for errors - other than Error (0) which means no error
* PHP: set PHP's error_reporting to E_ALL and see if PHP gives any notices/warnings/errors
* SQL: I'm not familiar with MS SQL, but it must have logging options and maybe log level settings - enable logging, set appropriate logging level and check the SQL server logs

Regards,
D

[AndyHolyer]

OK, I've made some progress here.

It's necessary the edit schema.php (I'll fix it with some ifdefs and submit the diffs when all this is solved) since MS SQL needs a datetime field specified as DATETIME rather than DT which MySQL allows. If you don't make this change, MS SQL quietly fails to create the required table.

That gets you through the install process. I haven't entirely solved this yet, but fetching

http://myhost/cmsmadesimple/

returns a 404. However a fetch to:

http://myhost/cmsmadesimple/index.php?page=home

works. Also the admin pages etc. all work. However the stylesheet formating comes up broken.

Looking at the source, I've worked out the reason:







If I change the & entity to its correct "&" then I get the stylesheet. Otherwise I don't.

However the apache site does the same thing... Hmm.

More news as I come to it.

The gloaters amongst you will be pleased to hear that there's a pronounced performance hit with the MS products: but as I said before I'm doing this for politcal reasons rather than technical.

[madelyn]

Hello:

Thanks about your help.  Works very well.


I have a problem, I don't know if  is the database or  adodb.

Cmsmadesimple cuts templates and long style sheets when keeping them.

I use PHP 5, MSQL Server Enterprise 8,0 ADOdb 1,42 and cmsmadesimple 1.0.4

I tried too with adob-lite.

Please tell me about the success stories.

Thanks about your collaboration,

Madelyn 

[AndyHolyer]

I think I've worked out the fix for this. And the bug is so amazingly, mind-bogglingly stupid that I'm still not sure that I've really cracked it. But it seems to work. In fact it's worse than that: no only does MS SQL have a feature that seems to have no utility beyond causing hard-to-find bugs, but PHP collaborates with it with the finesse of Laurel and Hardy to make the whole thing far, far worse.

If I told you that MS SQL had a parameter which specified the maximum length of a string returned in a query, you'd think I was mad, wouldn't you? Not the maximum length to store internally (which would have been bad enough), but the amount to return in a query. BUT THERE IS.It's called TEXTSIZE. Honest.

What possible utility could this parameter have? Was there a meeting somewhere in Redmond some Monday morning where the executive put forward: "Hey, what about if our customers wanted to store their data on our database, but only get the first couple of pages back? Can we do that, guys?". Sheesh.

OK, this seems mad enough. SO I fire up Query Analyser and type SELECT @@TEXTSIZE. I get back 64512. A funny number to have hardcoded in (I'd have expected 65536), but not something that I would expect to bite me in the bum.

Now we get to PHP's routine with the baggy trousers and bucket of whitewash. The MSSQL module has a parameter for TEXTSIZE (and also for TEXTLIMIT, which souds similarly worrying). If you don't specify it in php.ini, it has a default. The default is 4096. Bytes. Now, I was led to look at this when I found that the truncated templates seemed to be about 3825 cheracters long (I'm on Windows XP so I don't have nice stuff like wc, so I have to paste the text into Word and do a word count. Now, I@m just guessing that 3825 plus an extra character for each line-ending would add up to 4096?

There's shades of Bill Gates' comment about nobody ever wanting more than 640K.

OK, fire up emacs on php.ini. mssql.textsize and mssql.textlimit are commented out. Uncomment them, set them to 1000000, restart IIS from the sevices controller. Problem seems to have gone away.

So it's even more stupid than I first thought: It's storing the whole string internally, just only returning the first 4096 bytes. Again, why owuld anyone ever want to set this?

Now I've just got to figure out why it 404's on an empty page request.....

Drowning, not waving, Andy.

[madelyn]

Hello;

Thanks a lot,

There's shades of Bill Gates' comment about nobody ever wanting more than 640K.

OK, fire up emacs on php.ini. mssql.textsize and mssql.textlimit are commented out. Uncomment them, set them to 1000000, restart IIS from the sevices controller. Problem seems to have gone away.

So it's even more stupid than I first thought: It's storing the whole string internally, just only returning the first 4096 bytes. Again, why owuld anyone ever want to set this?

It works very good,  Thaks a lot .

Now I've just got to figure out why it 404's on an empty page request.....

I fixed this problem (momently) with movedPages plugin. 


God Bless you,

Madelyn

[ebrentnelson]

Hey guys! I think I found and fixed the problem with the 404 loading... it looks like there is a SQL error in class.pageinfo.inc.php.

Look at like 106, there is a query string that looks like this:

Code: Select all

$query = "SELECT c.content_id, c.content_name, c.content_alias, c.menu_text, c.titleattribute, c.hierarchy, c.metadata, c.id_hierarchy, c.prop_names, c.create_date AS c_create_date, c.modified_date AS c_date, c.cachable, c.last_modified_by, t.template_id, t.encoding, t.modified_date AS t_date FROM ".cms_db_prefix()."templates t INNER JOIN ".cms_db_prefix()."content c ON c.template_id = t.template_id WHERE (c.content_alias = ? OR c.content_id = ?) AND c.active = 1";

Well, in my case this was using 15 as my parameter... which makes the query look like this after being processed:

Code: Select all

$query = "SELECT c.content_id, c.content_name, c.content_alias, c.menu_text, c.titleattribute, c.hierarchy, c.metadata, c.id_hierarchy, c.prop_names, c.create_date AS c_create_date, c.modified_date AS c_date, c.cachable, c.last_modified_by, t.template_id, t.encoding, t.modified_date AS t_date FROM ".cms_db_prefix()."templates t INNER JOIN ".cms_db_prefix()."content c ON c.template_id = t.template_id WHERE (c.content_alias = 15 OR c.content_id = 15) AND c.active = 1";

The problem with this is that c.content_alias is a varchar field and thus cannot be compared to an integer. SO, I changed the simple ? (question mark) to cast( ? as varchar ) and that fixed it.