Click here to Skip to main content
15,881,089 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Hi all,

i'm pretty new at programming and i want to hear some idea's. Currently at work, we're using an excel spreadsheet that gives us after some calculations and moving and replacing, the decired new generated spreadsheet.

I want to change the application into a C# application (wpf). For functionality i don't think there will be much extra's in it, it's just some start of practice in wpf. Because in the future i will be problably working more with wpf.

i was thinking now: should i work with a database (acces or oracle) or still program it out of excel but with C#.

An other idea was to save the data in an xml file but pull it into a datatable from C# and do your magic in there.

Eventually i would be nice to handle huge amounts of data (up to 20k rows in excel) and processing fast.

I'm curious about your idea's. Some Pro's and contra's would be nice.

much thanks appreciated.

J

What I have tried:

In my opinion is working with an xml file pretty good.

you can save unlimited data to a txt file.
easaly to retract to a datatable.

I'm only afraid of the limitations of a datatable.

Other idea's are also welcome!
Posted
Updated 9-Jun-16 9:46am
Comments
BillWoodruff 9-Jun-16 19:45pm    
Unless you reveal significantly more information about what your application does now, and what you expect it to do in the future, I don't think really relevant advice can be given.

Personally, I find Excel an excellent tool to use in conjunction with C#, and a WinForms UI.

The question is: what key Database functionality does your app need now, or, in the future. Multi-user ? Create Reports ? Logging, archiving, security ?

Here is a simple Winforms example of using a datagridview with XML data:
XML to DataSet or GridView and back[^]

If you are not an experienced programmer I would avoid WPF, in my opinion this is much harder to start with than Winforms (but I'm used to Winforms of course).

Here is a more advanced tutorial using BindingSource (recommended !):
A Detailed Data Binding Tutorial[^]

XML is easy to start with, if the performance is too low, you can always adapt the code for database use.
 
Share this answer
 
Comments
Matt T Heffron 9-Jun-16 19:12pm    
Rick: You said: "If you are not an experienced programmer I would avoid WPF, in my opinion this is much harder to start with than Winforms"

I disagree. A lot of the difficulty many experienced developers have with WPF is unlearning the Winforms way of doing things.
Starting with WPF's declarative mind-set may be easier to pick up for an inexperienced dev. vs. an experienced one.
BillWoodruff 9-Jun-16 19:42pm    
Your comment interests me, Matt, because I am one of those persons quite grounded in WinForms who found trying to shift to WPF so weird and troubling I stopped using it.

A large part of that was the awkwardness, for me, of using the split-screen and having to mess around with XAML which felt, to me, like editing low-level UI spec in the Designer.cs component of a WinForm.

Yes, I was certainly aware, and still am, of WPF's more powerful data binding model, of its vector graphic engine, etc.

Another reason I withdrew from WPF development was the reports I heard from other developers that their projects were not performant at large scale. And, then there was MS's waffling on WPF's future in the Sinofsky/Metro roll-out debacle.

And, where is WPF today ? Yes, XAML is still around in UWP apps, but is MS truly supporting WPF.

Of course, you could ask the same questions about WinForms.
RickZeeland 10-Jun-16 8:58am    
Well, let me explain a bit more: my first seemingly simple attempts to use two forms and a progressbar took me days, and could only be completed after a lot of Googling and jumping through several hoops.
Ok, so it seems you can not work with forms in a normal way, but I still don't understand why.
The progressbar just won't work as it should, it does not update and display the progress, and you need a lot of tricks to get it going.
I could go on for a while like this, but I think you have got the point ...
First of all, don't use Excel, unless Excel is specifically required because part of the user's workflow is already in Excel and it cannot be changed. Even if this is the case, make sure you tried all the ways to get rid of Excel. Using MS Office in programming in is a big sign of low-tech; at the same time, it's not easy, rather wasteful. I already faced people pretending that Excel (a spreadsheet, first of all) is a database system. Better don't buy this fallacy. It can be connected as a database though, but why?

Now, there is a choice between XML and database. If database, it's the choice between different database systems. Here is the criteria for XML: you can use XML and get a lot of benefits from it (simplicity, lighter weight, and so on), only if you can meed two important criteria: 1) your whole data model is integral withing a single XML file, with no external XML documents (multi-file but single-document XML would be perfectly fine, say, you can have separate entities files, doctype, shared XML schema), 2) you are sure that all the XML data, the whole thing, when parsed, will always easily fit in the computer RAM. If this is not the case, especially second criterion, XML is not a good candidate for the replacement of the database.

An acceptable alternative to XML is JSON. But note that the Microsoft Data Contract, when used with XML, is fundamentally much more flexible than JSON. With XML, your data object graph can natively be any arbitrary graph, but with JSON it can only be a tree, unless you use some application-level (not contract-level) work around the problem, by introducing some special "structural" relationship keys; then you would have to maintain the data integrity by yourself. Please see:
Using Data Contracts,
DataContractSerializer Class (System.Runtime.Serialization),
DataContractJsonSerializer Class (System.Runtime.Serialization.Json).

What about the choice of a database management system? There are too many factors to discuss them seriously in one Quick Answer. You can start with reviewing the following lists and comparison tables:
List of relational database management systems — Wikipedia, the free encyclopedia,
Comparison of relational database management systems — Wikipedia, the free encyclopedia,
Comparison of object-relational database management systems — Wikipedia, the free encyclopedia.

One more warning against Microsoft products: in almost all cases, don't chose Microsoft Access. It's proprietary, not open-source, not free of charge, not lightweight but extremely weak in features, just not serious.

—SA
 
Share this answer
 
v4
Comments
Member 12267849 9-Jun-16 17:42pm    
Thanks for your response! This already helped me a lot. What i may have forgotten to tell you: is that the end solution always has to be .csv or .txt. How the data needs to be entered or saved doesn't matter.

So based on this info. What's your opinion of entering the data and saving it in a Oracle database and converse it to an excel sheet?
Sergey Alexandrovich Kryukov 9-Jun-16 18:40pm    
You are very welcome.

Truly, I have no idea what's the point of using .csv (I don't know what does it mean, "or .txt". .csv is text, and what is usually called "file name extension" does not matter at all), or using Excel, ever, and what is the problem of entering data in Oracle. Well, yes, Excel is a spreadsheet, so it's good to perform some ad-hoc calculation with formulas very quickly, something you don't have to preserve. But even with that, I lately more used my own JavaScript calculator. I think people take Excel way too seriously.

—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900