As of April 7, 2008, an updated version of my ePrayer module is now available free to registered site users. This version 04.02.01 provides the following fixes and/or enhancements:

• Reference to new ModuleController.SynchronizeModule method available in DNN versions 4.6.x and above has been replaced by the deprecated PortalModuleBase.SynchronizeModule method to allow compatibility with DNN versions 4.05.05 and above.
• Posting stats are now stored in a custom table rather than ModuleSettings fixing several errors due to caching of module settings data which caused posting stats to inconsistantly update as posts were added or deleted.
• Anonymous (unauthenticated) users may now be given post permissions in the module's permissions grid. In earlier versions, even though post permission could be granted to the anonymous user, an error would result when the anonymous user submitted the post.
• Tightened up security checks to ensure that anonymous users cannot delete or edit posts, request that an e-mail of encouragement be sent to the post's subject, etc.
• Corrected several bugs relating to moderation of posts, particularly with respect to approval/rejection of posts submitted by an anonymous user.
• Added a minimize/maximize icon to allow collapse or expansion of the request filter section at the top of the module's main view. For registered users, their preference as to whether this section is expanded or collapsed will be retained across visits to the site.
• In previous versions, only one set of e-mail templates were maintained across all portals of a single DNN installation. The e-mail templates could be modified by any portal administrator potentially resulting in conflicts in the multi-portal installation. Now, the host user can specify whether e-mail templates are stored on a per portal or per installation basis. The default is per portal allowing each portal to have its own e-mail templates that are editable by that portal's administrators without conflicting with those applied to other portals. If the host specifies that e-mail templates are applied per installation, the one and only one set of e-mail templates becomes editable only by the host user.
• Added a new function available to administrators on the action menu of the main module control. Manage Expired Posts allows the administrator to view which posts have expired (or which are marked with a particular status such as Withdrawn or Answered and created before a specified date) and selectively or as a group delete them from the database.
• Corrected a bug relating to the paging of the user's grid on the administrator's Manage Users control. In prior versions, paging beyond the first page of users would redirect to the main view.
• Provided a work-around to the rich text editor control used in the e-mail template editor on the module settings page not properly saving changes when used with DNN versions 4.8.x. 
• Corrected and/or approved a number of minor bugs relating to the user interface.

The new module version may be installed over existing versions without loss of data. If you have modified the module's e-mail templates, the modified templates will automatically be applied by all child portals until a child portal administrator edits them. From that point on, that child portal will have its own set of templates.

While I cannot commit to providing support for this free offering of the ePrayer module, I will try to address all questions you pose via e-mail or here in the forums.

I just installed this on a 4.8.2 install and received the following errors

NOT using an pbject qualifer and running MS SQL 2005 Express

I'm afraid I have not had any success finding why this and one other install that was reported to me failed when running the SQL scripts. At first I thought it was due to having a blank objectQualifier as that was the only common factor between the two failures. I have since tried several test installs with a blank objectQualifier with no problems.

Could you check to see which if any tables having a WESNet_EPrayer_ prefix were created during the install. If table creation had failed for the WESNet_EPrayer_Posts, WESNet_EPrayer_Requests, and WESNet_EPrayer_Users tables, the errors in table alias syntax generated during stored procedure creation may have resulted. In the other reported failure, only one out of twelve tables had been created but I'm not sure why.