Regular (daily) backups of both the database and log should keep the transaction log at a reasonable size. Depending on the database recovery mode, the transaction log may (simple recovery mode) or may not (full recovery mode) be getting backed up with the database if the BACKUP <databasename> T-SQL statement is being used.
If you are not doing the backups yourself, I would contact Network Solutions to confirm that the transaction log is getting backed up/truncated properly. I would specifically indicate that the transaction log is full and that they need to backup/truncate the transaction log for you.
If your database is MS SQL Server 2005 rather than 2008, you could also try the following T-SQL in MS Server Management Studio or whatever tool you are using to directly access the database:
USE <databasename>
GO
BACKUP LOG <databasename> WITH TRUNCATE_ONLY
GO
MS SQL Server 2008 no longer supports the WITH TRUNCATE_ONLY clause requiring the log file to be backuped to a physical device - something which you may not be permitted to do by Network Solutions. Several of the shared hosting providers that I use make Backup and Truncate Log commands available in the hosting control panel.
Here's a link to the MSDN documentation regarding database backup and log truncation for SQL Server 2008:
http://msdn.microsoft.com/en-us/libra...
With such a large ScheduleHistory table, I would also suggest that you not use the Host-->Scheduler commands to manually run the purge but rather try the following in Host --> SQL (with Run as Script checked):
USE <databasename>
GO
TRUNCATE TABLE {databaseOwner}{objectQualifier}ScheduleHistory
GO
If you run this command in SQL Server Management Studio, be sure to replace {databaseOwner} and {objectQualifier} with the proper values for your DotNetNuke installation.