Two products that I have looked into for converting an ASPX page into PDF:
1. http://www.html-to-pdf.net/
around $
2. http:/www.sautinsoft.com/help/rtf-to-pdf/net/help/about.htm
The companies above also have other pdf converters to covert rtf into PDF.
Here is why we choose to use the converter:
Earnest,
Converting the signed forms to PDF is the only reasonable option we have, considering these as legal documents and need to be retained for a lengthy period of time, tamper –proof. We have explored different converters that will achieve the functionality that we require and the following two products came close:
1. Sautinsoft HTML to PDF Converter: $338 per machine: Total of : $676 http://www.sautinsoft.com/
2. Outside Software Inc.: HTML to PDF Converter: $350 for development and deployment. - 20% off = Total: $280
The alternate option to buying a PDF Converter is to develop the converter ourselves, the downside being it will take at least Eight weeks to develop the software with similar functions. If we have the flexibility to deliver this mid September we can do away with purchasing the software.
Thanks!
-Anil.
We used the discount code provided.
Hi,
We can offer you a 20% discount for any company license that you purchase. Use our payment provider shareit and enter this coupon code: 20off.
Thanks,
Florentin BADEA
Product Manager
www.html-to-pdf.net
Wednesday, July 22, 2009
Thursday, July 9, 2009
ORM - Object-Relational Mapping
Just started using LinqToSql. Absolutely love it, typed data objects are just awsome. Co-worker
mentioned Subsonic, looks like it was pretty good. But I think linq may be faster compared to SubSonic or NHibernate.
Here is quick comparision of various ORM's by the SubSonic creator:
http://blog.wekeroad.com/2007/12/14/aspnet-mvc-choosing-your-data-access-method/
In my current project, the sys admin has mentioned he wouldn't encourage access to data except through stored procs, I agree with him. Fortunately using LinqToSql does allow invoking stored procs.
Here is an excerpt
"Many people believe that database access should always be performed through Stored Procedure to improve security (permissions can be granted only for those stored procedures an application should run), and for improved performance (query plans are cached between calls and better optimization can be carried out). LINQ to SQL fully supports Stored Procedures for general calls and the update, insert and delete operations, and in many cases improves the developer experience by freeing you from having to create input parameters by hand or having to create a strongly typed object collections to work with any returned results. However, solely using Stored Procedures eliminates the benefits of writing Query Expressions in the developer’s native coding language. There is middle ground though; you can use Stored Procedures for all Insert, Update and Delete operations and use Query Expressions for data retrieval. This allows the database to be secured against data corruption, while still allowing the developers to construct query expressions in VB or C#."
http://www.hookedonlinq.com/LinqToSQL5MinuteOVerview.ashx:"
mentioned Subsonic, looks like it was pretty good. But I think linq may be faster compared to SubSonic or NHibernate.
Here is quick comparision of various ORM's by the SubSonic creator:
http://blog.wekeroad.com/2007/12/14/aspnet-mvc-choosing-your-data-access-method/
In my current project, the sys admin has mentioned he wouldn't encourage access to data except through stored procs, I agree with him. Fortunately using LinqToSql does allow invoking stored procs.
Here is an excerpt
"Many people believe that database access should always be performed through Stored Procedure to improve security (permissions can be granted only for those stored procedures an application should run), and for improved performance (query plans are cached between calls and better optimization can be carried out). LINQ to SQL fully supports Stored Procedures for general calls and the update, insert and delete operations, and in many cases improves the developer experience by freeing you from having to create input parameters by hand or having to create a strongly typed object collections to work with any returned results. However, solely using Stored Procedures eliminates the benefits of writing Query Expressions in the developer’s native coding language. There is middle ground though; you can use Stored Procedures for all Insert, Update and Delete operations and use Query Expressions for data retrieval. This allows the database to be secured against data corruption, while still allowing the developers to construct query expressions in VB or C#."
http://www.hookedonlinq.com/LinqToSQL5MinuteOVerview.ashx:"
Subscribe to:
Posts (Atom)