DotNetOdf News

DotNetOdf now can create lists from a table template. Use it to generate address lists from a database, use it together with the single replacement to create an invoice with a letterhead and several positions, and so on.

The User Documentation was updated. There are also some more functions in the Winforms test project that you can “play” with different templates, view the XML source and the generated reports, and more.

The next version of the NotReallyORM framework will support the table templates with export from the LazyList object.

Winforms is not dead

There was a time I was really fascinated by WPF and began to dig into it. Well, you know its learning curve.  I must confess: When I re-discovered the advantages of Winforms, I used more time to improve my Winforms skills than to learn all this cool WPF stuff.

In fact Winforms is finished since .NET 2.0. But I want to share some arguments to use it during the next years, especially when you develop business applications.

1. Time is money, and your customers want you to use it as effectively as possible. Many software companies have a large code base of Winforms applications, helper classes, third party libraries and so on. Also there a many active developers with years  of experience in Winforms. Is your customer willing to pay the bill when you all give it up to sell him a WPF solution?

2. Business environments often use Terminal Services (RDP) to deliver applications. Business environments also often stick to old windows version. We have even customers using Windows Server 2003 and XP. There are many discussions in the Web about WPF on Terminal Servers or on aged operating systems. This is just one of many examples. You get interesting hints about fine tuning your WPF application and your Terminal Server (here you find a case study in German).  – But: My customer does not want to discuss. He wants a solution that simply works, even on his old machines that are very reliable when he is using his specialized branch software that was written in Visual Basic 6 ten years ago. You can say about Winforms whatever you want, one thing is granted: You will get working it on old systems (maybe you have to switch your compiler options to target framework .NET 3.5 or earlier). Will you also be able to do it when using WPF?

3. Microsoft does not actively develop Winforms any more. But it makes no efforts to bury Winforms. Have a look at Visual Studio 2012 (not the Express Version) and .NET 4.5. You do not only have the platform, but you also have a lot of up to date documentation on MSDN and elsewhere.

4. The Winforms Designer: In my opinion this is one of the highlights of Winforms. I have tried several GUI designers on different platforms: NetBeans for Java Swing, Eclipse with the Android toolkit, Visual Studio WPF Designer, Qt Designer for Visual Studio C++. The Winform designer tops all of them: Easy handling, transparent, understandable code generation at design time (good for the performance) and so on. Everything appears very mature and simply works.

5. Databinding is possible: From time to time you hear about the overwhelming possibilities of WPF concerning databinding compared to Winforms. I don’t deny the  flexibility of WPF in this area. But maybe Winforms can do more for you than you thought. The MSDN documentation on Winforms is good in most cases, but for Databinding it was not satisfying for me. As Winforms did not change very much during the last years, one of the older books from .NET 2.0 times maybe helpful (for example this or this). The next version of the NotReallyORM framework will show, how LazyObjects implement the INotifyPropertyChanged and are bound to a Textbox or a ComboBox.

6. Last but not least Winforms applications are cross-plattform. The Mono project supports .NET for Linux, including an implementation of Winforms.

What are your experiences with WPF and Winforms? I would be very interested in hearing controversial opinions.

 

DotNetOdf – Create Dynamic Reports from ODT and DOCX

Our customers often want applications that create reports from database queries. This may be invoices with customer data, lists and so on. So I decided that the database framework should have a brother named DotNetOdf. This library was inspired by an older open source project I launched several years ago. You can insert data (for example a customers name and address) into your reports with just a few lines of code, and your customer can maintain the reports himself. During the next time I want to add a function to insert lists (the positions of an invoice for example).

The latest version of the NotReallyORM framework supports this library, for the LazyListRow class now can export its data into a dictionary. The DotNetOdf User Documentation will explain this to you more detailed.

 

The Cover Picture

I was asked where the cover picture of this blog is taken from. Some part of a factory, or something like this, this was the guess.

Far away! So I am forced to disclose the secret. I took this picture at the Vogtlandarena, a world cup ski jump in Klingenthal, Saxonia (Germany). You see the elevator that takes the athletes and the visitors to the top of it. It was a fascinating atmosphere for me, so I took a lot of photos.

Framework News

After my holidays I started to write a User Documentation for the framework. You can try the examples in it without downloading the whole project, just get the DLL (it’s zipped for security reasons). The documentation is not finished at all, but you get a first overview of the concept and a step-by-step example for simple CRUD operations.

I also decided to downgrade the whole project to .NET Version 3.5. Especially in business environments you still have a lot of older Windows XP installations, sometimes locally, sometimes as remote desktop. With XP SP2 there should be now no problem to use the NotReallyORM framework.

 

Compound Primary Keys and Foreign Key Constraints – Traps and Oddities in SQL Server Manager

Compound primary keys sometimes seem a more natural approach than the use of auto-increment integer keys. Now I discovered some unexpected behaviour when I tried to reference them as foreign keys from another table with the SQL Server Manager.The basic documentation you find here and here on MSDN.

What I did not find there: The order of the compound primary keys as stored in the database is not necessarily the same order you see in the object explorer of the Server Manager.

So when you try to establish a foreign key constraint you may get an error and SQL Manager will not be able to create it. After some googling I found hints, but the best workaround was told me by a colleague. So this is the recipe:

Go to the table with the compound primary keys in the object explorer, right click on “Keys” and choose “Create Script”.  You will find some Transact-SQL like

ALTER TABLE TableWithPrimaryKeysADD CONSTRAINT PK_TableWithPrimaryKeys_TransactionID 
PRIMARY KEY CLUSTERED (TransactionID_1, TransactionID_2, TransactionID_3)

When you created this table with the SQL Manager, the order of TransactionID_1, TransactionID_2, TransactionID_3 is the order you marked them with ALT-Click, before you chose them as primary keys (really, try it out!).

Now you want to construct the foreign key constraints. The foreign keys in this have the same names like the corresponding primary keys. To do this in Transact-SQL you will need something like this:

ALTER TABLE TableWithForeignKeys ADD CONSTRAINT FK_TableWithForeignKeys_TransactionID_1 
FOREIGN KEY (TransactionID_1, TransactionID_2, TransactionID_3) 
REFERENCES TableWithPrimaryKeys (TransactionID_1, TransactionID_2, TransactionID_3)

You see the order of the foreign keys? They must have exactly the same order like in TableWithPrimaryKeys. For me this a reason to work more with Transact-SQL than before. It is better than to rely only on the the SQL Manager (nevertheless I still find the manager quite useful in many cases.).

Framework News

During the last week I had to do with compound primary keys at work. Sometimes I find them more appropriate than my beloved auto-increment integer keys.

Reason enough to test the NotReallyORM framework with them. The framework was already equipped to use compound keys. After the tests I added some fixes. It now works fine with those keys, as far as I can see. In one of the next versions I plan to retrieve those keys automatically from the database.  I found a nice SQL expression for SQL Server for this purpose (explanations only in German, sorry).

Download the latest version NotReallyORM_0.52 and try it out.

Framework News

I made some tests to store data from a form to the database more effectively. The CRUD functions and the transactions seem to work fine now. I am still looking for a more effective way to store data from a form to the database, without too much boilerplate code. And it should work with WinForms. Standard data binding with WinForms (bind a control to a data source) has not convinced me yet. I know WPF has better features for data binding, but I want to be independent from WPF (more on this topic another time).

Download NotReallyORM_0.51, try it out, read the comments in source code. And, yes, you can use the framework for ASP.NET, too (it should be thread safe).

Storing Binaries? In the Database, of course!

This blog is driven by WordPress. As far as I can see WordPress would never try to save pictures, videos or pdf files into its MySQL database – in the database you find only links to the file system. This makes sense to me. I cannot imagine a better way to deliver web pages fast and reliable, especially when you have scenarios with many requests per second.

In my job we normally do not program web pages. Will the principle “Do not store binaries in the database” always fit? I remember the time two years ago when I began to design a document management system. It should store 1.6 million pages per year, with multi-user access in a terminal server environment, powered by an SQL Server database on a 64 GByte machine as back end. The customer’s hardware provider gave me two advices: 1. Use transactions. 2. Store the documents in the database. Well, the system is now working productive for one year, and I am very grateful that I followed his hints.

Today I can warmly recommend storing binary data in the database. It is reliable and stable. You can use complex database transactions that include storing the binary, storing process information, storing foreign key relations and so on. You can easily handle concurrent access. And last but not least: The user experience when saving and retrieving documents is not “very slow”. It is just a bit slower compared to working with documents in the file system. I admit there is one restriction. You should not handle 500 MByte videos this way. The documents I am speaking about are 100 – 500 KByte, mostly PDF format. So this is not a good solution for YouTube…

There is a very good article from Microsoft Research that made me to dare this approach in a production environment. I also included the storing of binaries in my NotReallyORM framework.

What are your experiences on that? So far I have tried it only for Microsoft SQL Server. Would be interesting to know how a MySQL database would behave, for example.

Why I do not use ORM, or: The Beginning

“It’s time to become a real modern software company. We should begin to use an ORM framework in our new projects, maybe the latest version of the Microsoft Entity Framework. Everybody uses ORM nowadays, Microsoft pushes it, why we don’t?” That’s what I told the colleagues in my team some months ago.

It was the time when I began to read books about Microsoft Entity Framework and set up some experimental applications. I was fed up with writing boilerplate code for simple CRUD operations and hoped for some magic that was promised when you use these Entity Objects with data binding. Unfortunately the members of my team were not that enthusiastic about my ideas. You must know: We do a lot with SQL in our development, and we never made bad experiences with these “old school” handmade queries.

After some discussions I thought about my “modern” point of view and asked Mr. Google about some critical writing on ORM. One of the most inspiring texts for me was Kenneth Downs’  essay “Why I do not use ORM” in his blog. There you also find a newer version with some other aspects. Well, this was only the begin of the journey. But it was one of many impacts that led me to start this blog and to try an alternative with the NotReallyORM framework.

So I invite you to share your thoughts with me, to try out the framework, to make suggestions and to ask some questions about mainstream thinking.