I've seen some sites with only just a few forums and a lot of posts. And, then I've seen sites with several forums and a lot of posts. I mean that I have seen a lot of posts either way, but the amount of forums were usually either few or many.
If there are a lot of members on at the same time and often, which is a better set-up for a Snitz site? Does it the database, server, etc. perform any differently between the two set-ups?<

it entirely depends on what your members do.
if lots of them visit default.asp then it is best to keep the number of forums low, if they rarely visit default.asp then the number of forums is pretty irrelevant. It is always best to keep the number of unarchived posts lowish as it helps with performance especially searching<

Thanks Huw. Personally, I like the fewer forums because of less remembering what forums do what, but I have seen the several forums approach that was done nicely and in good taste too.
I forgot to ask. Is your answer the same about searches ... regarding the amount of forums as in it is irrelevant?
Thanks again! <

the only relevance with forums on the search is to the load time of the search form, it should not have much effect on the actual searching.<

I have plenty of forums on GAPE as you can see, and I'm still using Access DB (60Mb now) and I'm starting to have problems in some posts when the user gets the error script timeout when showing the pages of a post.
I know that SQL will be much better, but I still hadn't the courage to pass all to SQL
FORUM_REPLY has 32900 rows
FORUM_TOPICS has 2700 rows<

Thanks guys!
I just didn't want to stack the deck up on a couple of forums only to have performance degrade in the long-run. I suppose I am simple, but I really do like the few approach most of the time.
Hey, Bruno at 60 MB does that mean that your archives are many? It looks like you have about 35,496 non-archived posts.
<

I have nothing archived
I read so many posts regarding problems retrieving and searching archived posts, that I do prefer to have all open and searchable.
...or I did misunderstood the Archive function?<

From my experience when the archives become very large, it is often difficult for the standard Snitz search to finish without timing out. This isn't a snitz flaw. I don't think.
This problem is a bit the result of when archiving is not performed regularly. So, when the archiving times out and then the same forum is archived again, the replies get duplicated in the archives because the originating topic does not get the point where it can be successfully deleted (again, this is because the replies did not finish archiving).
If it will help you, I wrote a little mod that helps with archiving in more segments than the standard Snitz allots for: http://forum.snitz.com/forum/topic.asp?whichpage=2&TOPIC_ID=67666#384563

You may want to contact your host to find out the longest time that they allow a script to run on your account. That may help you gauge what is going on.
I need to do something more to my little mod like check to see if the reply_id being archived is already an existing REPLY_ID in the FORUM_A_REPLY table. If it is, then skip it, and move on to the next reply_id and verify it until the process can start fresh with the correct reply_id in order to start the archiving process again. Also, for existing reply_ids that are duplicated, do a count of the archived reply_id, and if the count is more than 1, then delete the duplicates else skip it. That would actually be the first process I would run, and make the other a separate process. I am thinking that these things might help with cleaning up duplicates and not duplicating reply_ids in that table. Maybe it might take some of the fear factor out of archiving.
Honestly, I think duplicates happen more often than not because folks don't realize about the archive process timing out due to server limitations. Then the duplicates occur, and folks get frustrated and move on and away from it. In a perfect situation though, I assume that the standard Snitz archive process would work flawlessly.
<

if it is true what you are saying... why not perform a TOP 100 or even 200 and archive that... for example, archive the first 100 topics that were not archived.
this will never take that much time and it is possible to give a nice progress bar to the user.
What do you thing? wanna try do this (MOD) with me?<

Sure, I don't mind helping.
<

I'm still having problems this morning with my outgoing mail server, so I may not be able to respond via e-mail anytime soon that I know of at the moment.<

morning hum... it's 16.46 here - I'm in Romania until Tuesday
but soon I get home, I will create a new topic so we can share ideas if we need (and or email is still n a bad mood)
until then, I will see what Archive is programmatic or it's only cut/paste REPLY and TOPICS into the FORUM_A_ ... tables?<

Well, the standard process works like this:

- Start with associating the topic id with all of its reply ids. - Archive all of the associated reply ids (as a batch) into FORUM_A_REPLY
- Delete all of the associated reply ids (as a batch) from FORUM_REPLY
- Archive the topic id into FORUM_A_TOPICS
- Delete the topic id from FORUM_TOPICS
- Completed

Of course, there are some other update things like for the FORUM table, SUBSCRIPTIONS table, etc conducted along the way, but those are the highlights.
I don't think that cutting and pasting would be worth your time honestly. <

ok then, I will look depth into the link you gave me that has the SP from Rui and I will let you know what I will try to do, but I need first to understand correctly all the steps of the Archive so I will not miss a bit <

Works for me! <