Limit on page size/database warnings?

[paranoidandroid]

Hi, just wondering if there's some default limit on how much info/table length can be contained on any one page and, if so, how do you increase it? This might be a stupid question, but I'm asking because I was experimenting pasting some author chronology tables of varying lengths onto the main content areas of pages and noticed that those with very long lists mess up the page, pushing the footer to the top of the page, etc. Is this something that just requires a css edit?

Edit: You can see what I'm talking about here:

http://www.strangeborders.com

Navigate to the "chronology" links at the bottom under literature/authors/by name and see that the chronology page under Bradbury is messed up, the footer squashed to one side at the bottom. If I were to add any more rows to the table, the footer would end up at the top.

TIA!

[Ted]

Yes, it's just a css issue.  I don't know the specifics, since I didn't really have anything to do with the default templates, but I do know that a page can be any length (within reason...  2 gigs with mysql I think.  ).

Any of you CSS gurus have a clue as to how to fix this?

[paranoidandroid]

haha, that figures. Sorry, I should have checked that first, don't know what I was thinking.

Thank you. 

[paranoidandroid]

Lol, I hate to end on a bad note, but all's not well in my usually beautiful world. I might just be so tired now that I'm imagining things but there seems to still be some problems with this. I'm not sure it will do you any good to look at the code because it's probably gonna look messed up. But it's messed up because for some reason I can't save the entire table. What you would see now if you looked is just a little more than half of the actual table list I pasted and saved, or tried to save - it won't save more than that. I think that's probably what happened when you checked it last time, it was just an incomplete save, so the code was messed up. So there still "appears" to be some limit on the table size at this point. I could be wrong, though. I'll look at it again tomorrow when I'm not half-asleep.

'Probably not gonna turn out to be that important to me anyways, to be honest, 'cause I doubt I'll use that kind of format.

Night all!

[paranoidandroid]

Well, I just got up, so I haven't got around to anything yet, but I was dropping code from dreamweaver straight into the 'source' in the cmsms pages.  /yawns

I have an "intuition" that things might be easier if I just drop that footer. 

[paranoidandroid]

Patricia, I disabled the editor and tried again, but still no luck. I was able to get a few more rows to save than before but it's still doing pretty much the same thing. I hate to do this (boy, it's gonna make this page long), but I'll just plop the table code down here and maybe you can tell me if there's anythign obviously  wrong with it:

Edit:  Okay, I couldn't do that, because it's too long:

"The message exceeds the maximum allowed length (20000 characters)"

Sound familiar? 

[paranoidandroid]

All I know is that apparently the same limit on your boards is imposed on regular cmsms pages. Since they're two different scripts I would imagine that someone manually imposed these limits....? - either that or there's just something that needs to be edited with the css. You got me. 

[paranoidandroid]

Okay Patricia, I'll get aroung to it before too long, let you know if it works. Thanks.

[paranoidandroid]

I went into phpadmin to check that field. There was this error:

'Warning PRIMARY and INDEX keys should not both be set for column `content_id`'

I thought something must have got scrambled in my install, so I just said to hell with it and deleted my database and created a new one (I've made copies of all css, etc.), reinstalled cmsms, then rechecked the database. The same exact error message is there. Did it all again, a third time: same results. Is this something I should ignore? Is it a bug? Some lack of my server? 

Edit :In fact, there's little exclamation symbols all over the cmsms db... I've got 8 MySQL databases installed presently, this is the only db install of them that's showing errors, so I'm kind of doubting it's an issue with my server. Man, I'll get back to this later. 

[paranoidandroid]

So....just wondering, has anyone else taken the time to actually look at their databases created by the latest beta? Is this just an aberration on my end, and everyone else's installs are fine?

Running:

PHP version  4.4.2
MySQL version 4.0.22-standard-log

[paranoidandroid]

Anyone? Anyone? Bueller?

[Ted]

Ok, some more research.  Text fields in mysql are 65535.  There is also mediumtext and longtext.  I've a feeling that the 20k limit might be comeing from FCK, because there is no checking at alll for length on the cmsms side.  Try pasting all of that stuff without FCK on.

[paranoidandroid]

I did try that, wishy - read up several posts.

Any ideas on the db errors I mentioned? They are there on every fresh db creation so it obviously has nothing to do with me tinkering with the script afterwards....

[paranoidandroid]

Thanks Patricia. I set the field to longtext so we'll see what happens, I might not get to play with it tonight. Here's the warning message I see, though:

Keyname  Type  Cardinality  Action  Field
PRIMARY PRIMARY 29  Edit Drop content_id
prop_name
content_id INDEX None  Edit Drop content_id
prop_name
Warning PRIMARY and INDEX keys should not both be set for column `content_id`

Those warnings are on all the content fields, a couple of the admin ones, a css or two, etc., most just say:

Warning No index defined!


I'll check them out after I've build up a few pages, etc.

Thanks again.

[paranoidandroid]

Okay, the good news is that setting that field to longtext allowed me to finally paste that entire table on the page and everything's in the right place, so that's all it was. Thank you.

The bad news is the db warnings, doesn't look like there gonna go away by themselves. However, since I haven't seen yet that they're actually adversely affecting anything, maybe I can just ignore them.