I use the ABCPdf .Net module quite a bit in projects.  It’s perfect for generating and manipulating PDF files in server-side ASP.Net code.  But more than once, I’ve encountered this error and can’t remember the solution.
Finally I remembered the cause of the error.  You have to enable 32-bit applications in the IIS application pool here.
Go into IIS Manager and choose Application Pools. Find the app pool assigned to the site running ABCPdf.   Select the App Pool on the left, then click ‘Advanced Settings’ on the right side. Now change the Enable 32-bit Applications setting to True and apply.
When you’re done, stop and restart your app pool.  Now try your page again.  Hopefully that’ll fix it for you like it did me.
ABCPdf is available at www.websupergoo.com if you have need to stellar PDF manipulation in .Net.
Came up with an awesome mod for the Order Manager screen tonight.  It highlights orders that are placed from non-US IP addresses.  This makes it incredibly easy to identify potential fraud orders in your storefront.
This mod works with a local GeoIP database too, so there’s no lookup limits or bandwidth spikes to worry about.
Geographic IP lookups are a dime a dozen on the internet.  But the vast majority of these lookup sites will throttle the number of requests.  This creates a slow and often frustrating limit on the usefulness in a production environment.
By leveraging a local database, it becomes far more efficient (and less costly) to implement GeoIP lookups in your AbleCommerce website.
I found this today and was completely floored in it’s simplicity.  Works like a charm:
protected void GridView1_RowDataBound(object sender, GridViewRowEventArgs e)
if (e.Row.RowType == DataControlRowType.DataRow)
string ProductId = DataBinder.Eval(e.Row.DataItem, "ProductId").ToString();
string Location = ResolveUrl("~/Details.aspx") + "?ProductId=" + ProductId ;
e.Row.Style["cursor"] = "pointer";
Ran into the most curious issue after migrating live sites running SQL 2008R R2 into Amazon AWS virtual instances.  There was a job scheduler module that populated a queue table based on triggers from other tables.
The triggers used the T-SQL GETDATE() function to log the current datetime of the transaction being triggered.  However, after migrating SQL to a virtual instance, the “current” datetime was off.     The trigger code was seeing the wrong datetime value every time GETDATE() was called.
I even went so far as to light up a local SQL install and compare it to the instance SQL install.  Executing SELECT GETDATE() on separate copies of SQL doesn’t report the same values.  Even though both server OS environments have the same date and time zone settings.
Finally I found another blog post about Azure but discussed the same problem.  Apparently when SQL is run in a virtual instance, it ALWAYS reports GETDATE() in UTC format regardless of the server OS time zone settings.
The IIS instance didn’t seem to have any trouble with it.  The issue was specific to the SQL OS.
One more reason (and lesson) why it’s better to store your SQL datetime values in UTC format so things like this don’t happen in the first place……