Member Avatar for belometer

Hello there,

I'm in the process of learning C# and windows forms. What I'm trying to do is adapt some scripts I have already made using PHP and MySQL to work in a windows environment and GUI. I previously wrote it using PHP because I was already familiar with the language and could output the information I needed to a web browser, so didn't have to mess around with coding a proper GUI, but would now like to do so. I've been trying to work out the best way to do this, so have a few questions:

1) Would I be better off not bothering with MySQL and using MS SQL instead? Ultimately people will be able to download what I am making so I'm not sure which would be the best option in terms of when a user is installing all the necessary bits and pieces.

2) Could I ditch SQL databases entirely and run queries of some sort on flat text files (or excel files)?

3) I've been messing around with DataTables, and data sources of various types. What's the best one for displaying the contents of a database in a window? I'm not sure what the pros and cons are here.

Thanks!

  • 2 Contributors
  • 2 Replies
  • 191 Views
  • 9 Hours Discussion Span
  • Latest Post Latest Post by belometer

Dani AI

Generated

Practical, modern roadmap for moving PHP/MySQL scripts into a C#/WinForms app — answering the three points raised by and following up on ’s idea of an embedded DB.

For a redistributable Windows GUI app, prefer a single-file embedded database (SQLite) so end users don’t need to install a separate server. SQLite is small, reliable, public-domain, and widely used; for heavier multi-user or server-style workloads choose SQL Server Express / LocalDB or keep MySQL as a server component. Note that Microsoft’s SQL Server Compact (CE) is now deprecated and its extended support ended in 2021, so it’s not recommended for new projects. (sqlite.org)

Flat files or Excel work only for tiny, single-user tools — they lack transactions, indexing, and safe concurrent writes. A better lightweight alternative is SQLite (single file) or a JSON/CSV file plus careful locking; for .NET projects the Microsoft.Data.Sqlite ADO.NET provider is the usual, easy-to-bundle choice (NuGet). (learn.microsoft.com)

For display, use the WinForms DataGridView bound through a BindingSource. Prefer binding to typed lists (BindingList<T> or a BindingSource pointing at domain objects) rather than raw DataTables for cleaner code, change notifications, and easier mapping from your PHP arrays. For large result sets use virtual mode or server-side paging instead of loading everything into memory. Example binding pattern: 


var list = new BindingList<Customer>(LoadFromDb());
bindingSource.DataSource = list;
dataGridView.DataSource = bindingSource;
``` ([learn.microsoft.com](https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/datagridview-control-windows-forms?utm_source=openai))

Practical migration tips: keep SQL logic where possible (parameterized queries), implement a small data-access layer so the storage backend can be swapped later, and choose a data-access approach that fits the app — Dapper for lightweight, SQL-centric code or EF Core if you want an ORM with migrations. When packaging, either include the native SQLite bits with the installer or bundle the SQL Server Express/LocalDB installer if you need a server instance; always test installs on a clean Windows VM. ([nuget.org](https://www.nuget.org/packages/Dapper?utm_source=openai))

Recommended Answers

All 2 Replies

Member Avatar for PsychoCoder

1) I would stay with MySql, depending on what the application is doing. If you go with MSSQL your users would have to pay to license it unless you were to go with the Compact Edition and MySql is free.

2) You could if you want, but it makes more work for you. Working with flat files isn't nearly as easy as working with a database. If it were me I'd stick with SQL Server Compact edition, with that you can embed your database into your application.

3) DataSets are easy to work with. I personally use generics for working with data a lot, I feel they dont have the overhead of some of the data objects in the .Net framework

Member Avatar for belometer

That sounds great - thanks for the rapid reply! I will definitely take your advice, and from what you're saying it sounds like SQL Server Compact is the way to go. Am I right in thinking that if I include that with my application, I'll be able to have multiple tables and databases all handled within the application itself, rather than having to get any additional programs installed on top?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.