views:

717

answers:

3

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?

A: 

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.

Randolph Potter
So I can write and read from access from a VB.NET app with no problems? like, just adding a new row, and things like that? what way would it access it, from LINQ right?
Camilo Martin
A: 

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.

HipCzeck
Would that look like...:Dim ConSQL As New OleDb.OleDbConnectionConSQL.ConnectionStringConSQL.ConnectionString = "Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=.\file.sdf"ConSQL.Open()Dim CommandSQL As StringCommandSQL = "SQL command here"Dim da As OleDb.OleDbDataAdapterda = New OleDb.OleDbDataAdapter(CommandSQL, ConSQL)...Con.Close()?? would it be like that? or I'm doing it wrong?thanks for your help.and, second question: my users need SQL server compact installed?? or just the .NET framework will do? I want to make this as user-frendly as possible.thanks again! ^^
Camilo Martin
(it looks like it chopped the CRLFs, the code doesn't look very readable like that sorry >.<)
Camilo Martin
In theory, the provider can be used in lieu of the full package for access to the back end datastore. So, if you are using the MS Access/Jet provider, you don't actually need to have MS Access on the client machine. I'm not sure that the SQL CE provider is included by default on windows machines, and I'm not sure if the provider is wrapped into the executable or not (I haven't worked with SQL CE). The .NET framework is needed to run any app developed in Visual Studio .NET. I tend to use Access .MDB files, because they're relatively portable, fast and robust without being too large.
HipCzeck
thanks ^^ so, MDB files are just a little bigger with no obvious downside? ever had any complication with them?
Camilo Martin
+1  A: 

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.

blu