Question

My database must be updated at arbitrary intervals, manually, with new info to put on standart tables that don't require structural modifications. one app will update the database.
Another app, the one I will distribute (to friends and family only, but doesn't require any security feature to it, like encrypting the database) will read the database and use its data on labels, listviews, etc.

The problem is, I'm the perfect definition of full-fledged n00b at programming of any sort, and still don't know what database to use.

I thought that I should use a SQL CE (*.sdf) file, and store that database thing on an FTP. then, I could download it and get data from it everytime the "client" app runs, and certain button ("connect") is clicked. After some hard-core googling, I found out how to connect to the sdf thing, using this connection string:

Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\Documents and Settings\Camilo\JCTM.sdf

So it connects, or at least didn't show any error.

I don't know if it's a good idea to use sdf SQL CE files as databases, if it's too hard maybe I should go for XML? what do you guys suggest, what is the easiest way to implement very simple databases in VB.NET?

By simple databases I mean: - no search needed - no advanced features except storing strings on tables with columns and rows - easy to access, read, edit, etc. by different VB.NET apps

Is sdf a good idea?

Was it helpful?

Solution

Luckily for you, you can abstract away the need to be concerned with which back-end database you use to store your data.

Technologies such as ODBC (Open Database Connectivity) and OLEDB (Object Linking and Embedding, Database) allow you to limit your concern for the backend datastore to the task of crafting your connection string. In your example, the connection string says, "I'm going to connect to a SQL Server CE database via its OLEDB provider, and it's physically located over on D:/...

Within the code, you use standard OLEDB mechanisms to access and manage the database. Because of this abstraction, you can use OLEDB providers for SQL Server, Oracle, XML, Access or comma delimited text files as your backing store if you wish, and the only change you need to make to your code is the connection string. Your choice then should be to pick the database that you have the tools and know-how to set up and manage initially.

OTHER TIPS

I would recommend Sql Server Express Its free and can be redistributed with .net applications as part of the install process.

The challenge will be syncing the changes between the different clients. If you have access to a FTP server, you may have the ability to host a website in IIS. If you can do that you can just use webservices and read against one database instead of copying one local.

I'd start with Microsoft Access because it has its own UI, and can play well with .NET.

You can also try the ADO.Net implementation for SQLite, which I've also found very useful.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top