Author |
Topic  |
Etymon
Advanced Member
    
United States
2396 Posts |
Posted - 29 August 2008 : 05:19:44
|
quote: Originally posted by cult_of_frank
That looks pretty handy, actually... so I can pop this code in and archive for a year and it will break it into incremental pieces? Why are months 72 though?
You'll see that the drop down starts out first presenting you with 52 weeks starting with 1 week and ending with 52 weeks. Then the list will also present you with 72 months starting with 1 month and ending with 72 months.
If your forum is just a year old and relatively small, then you can start out with either months or weeks.
If you start with months, see if it takes a while to process the posts. If it takes a while switch to weeks, because it will only take longer as you get closer to your current posts.
If you start with weeks, then start at week 52 to get all the posts from that week to as old as possible. Then select week 51 to get the posts created between week 51 to week 52 ... and so on.
If you select week 1, then you are selecting all of your posts. That's not the idea, and is worse than if you did not use the code. You could cause duplicates by selecting that first off the bat. Start out with the higher number of weeks and work toward the lower.
If you have an older site, and you think the month selection is too large of a denomination and you think you may need more weeks further back, then just increase for counter = 1 to 52 to something higher. The same is true for increasing the amount of months in the code.
I start out with the months. If everything is going smooth, then I stay with months, but if I get into a really slow spot that I think is iffy regarding timing out, then I switch to weeks. If weeks get iffy, then I add another routine to include days. And, so on for hours if weeks get slow too.< |
Edited by - Etymon on 29 August 2008 05:27:12 |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
Posted - 29 August 2008 : 11:52:45
|
Ok, to complete the code needed for a new archiving function, after creating the stored procedure, replace the subprocedure <b>subArchiveStuff</b>, in admin_forums.asp by the one posted here. This will only work for your replies table structure and for topics and a_topics tables with the exact same structure. Of course, it's good only for SQL Server DBs.
As I said, this is much less prone to timeouts and in case of errors, it will revert the changes done, as it uses transactions. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
Etymon
Advanced Member
    
United States
2396 Posts |
Posted - 29 August 2008 : 14:42:45
|
Hey! Thanks Rui! < |
 |
|
cult_of_frank
Starting Member
Canada
20 Posts |
Posted - 29 August 2008 : 16:02:35
|
Wow, I can't believe you went to all that effort for me, that's incredible. I managed to figure out how to install a stored procedure, did it, modded my admin_forums.asp, and ran it. It worked beautifully. I didn't realize the other method left dupes in the archives, I might have to go and look, but otherwise I am very impressed. Thank you very much!
Etymon, I didn't get the chance to use your script, but also thanks for posting that and trying to help. I definitely would've gone that route if I'd been unable to use stored procedures.
Now to see if that will solve memory issues...< |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
Posted - 29 August 2008 : 16:30:38
|
Glad it worked well . I didn't do it all anew, had to change some stuff I had done before.
I've done some work for SQL Server based forums, to improve performance, on the archiving, count updating and searching areas. Some things I posted as mods, others can't be posted as mods, as they have requirements that not all users are able to meet. Lately, with new MySQL versions, some things can be applied to MySQL, others not that much.
Anyway, what matters is that it worked for you .< |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
texanman
Junior Member
 
United States
410 Posts |
Posted - 11 August 2009 : 12:47:05
|
Rui, I am having a similar issue as cut_of_frank did. What does your code do? Does it free disk space? I have 200MB disk space and can not be increased and I am getting the error when archiving or replying to a post (no space to allocate etc). Thanks |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
Posted - 11 August 2009 : 17:49:06
|
Hi,
No, unfortunately it does not free disk space. It just archives stuff much more efficiently than the standard Snitz code. Does the 200 MB limit include log file size? |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
texanman
Junior Member
 
United States
410 Posts |
Posted - 11 August 2009 : 18:03:38
|
Yes, it deos. It is about 30-40MB allocated for logs. Both data and log spaces are near full. |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
|
texanman
Junior Member
 
United States
410 Posts |
Posted - 11 August 2009 : 18:14:55
|
LOL I have no idea! The host doesn't allow Enterprise Manager or any other SQL management software "for security reason". I can only use their own SQL admin. |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
Posted - 11 August 2009 : 18:33:13
|
Well I would say that you need to find that out ASAP. I also begin to think that you may have outgrown your host / hosting package?!
You can try to set your recovery model to simple by using:
ALTER DATABASE databasename SET RECOVERY SIMPLE
See if it makes any difference. |
Snitz 3.4 Readme | Like the support? Support Snitz too |
 |
|
ruirib
Snitz Forums Admin
    
Portugal
26364 Posts |
|
texanman
Junior Member
 
United States
410 Posts |
Posted - 11 August 2009 : 20:00:29
|
Thanks. This is after changing the recovery model and shrinking.
Database [ db ] Database size Database size : 190.05 MB Unallocated space : 0.79 MB Database space used Reserved : 193304 KB Data : 186280 KB Index : 5744 KB Unused : 1280 KB
|
 |
|
texanman
Junior Member
 
United States
410 Posts |
Posted - 11 August 2009 : 20:13:37
|
After truncating FORUM_A_REPLIES:
Database size Database size : 191.06 MB Unallocated space : 112.75 MB Database space used Reserved : 78656 KB Data : 71792 KB Index : 5736 KB Unused : 1128 KB
|
 |
|
Topic  |
|
|
|