DotNetNuke Modules - Caching
A couple of days ago I showed a method for finding a module on another page. Néstor Sánchez pointed out that on a large site, this could cause a significant performance issue. He suggested, instead, registering the location of the module with the database when it is created on the page it is on.
I was looking for a way that would allow the module to move around, and had initially thought that a module-centric method would require the end user to do something. Ah well, that’s one of the problems of working alone. (And one of the advantages of blogging about what you’ve done.)
So, let me show you the way I did solve the performance problem. It isn’t quite as efficient as what Néstor recommends, but it is usable in other situations and it is a performance solution you need to know about. (more…)
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Last week we talked a bit about Inter Module Communication, the ability of one module to notify another module on the page that something needs to happen without requiring a post back. The other need you may have is something I refer to as Cross Page Communication. This is not a DotNetNuke term, I just made it up today.
Once you have your database created, you’ll want to get some tables set up into it. To do this, you’ll need the CREATE TABLE statement that can be issued from the connection object once you’ve established the connection.
A couple of weeks ago, I was working on a project that required me to unzip a file. There is only one text file in the zip, so using a full-blown library like 