|
You can use MySQL. It's powerful.
|
|
|
|
|
Few choices (registration needed in most):
- SQL Server Express Edition for multiuser environment
- SQL Server Compact Edition for singleuser environment
- Oracle XE
- IBM DB 2 Express-C
- MySql
and there are lots more but I think these are the most useful.
Mika
|
|
|
|
|
How about SQL Server Express?
Use Live Search to find it.
“If we are all in agreement on the decision - then I propose we postpone further discussion of this matter until our next meeting to give ourselves time to develop disagreement and perhaps gain some understanding of what the decision is all about.”-Alfred P. Sloan
|
|
|
|
|
The 2 best options I know of are MySQL and PostgreSQL. A couple of differences I've noticed:
1. MySQL Community server is free, unless you redistribute your project not user the GPL license. In this case, you would need to purchase a license. However, if your project is distributed under GPL, then it's still free.
2. PostgreSQL is licensed under the BSD license, so it is completely free to use in any and all situations.
3. From personal experience, MySQL seems to be much faster than PostgreSQL, so if speed is an issue (as it is in my application), I'd go with MySQL.
Dybs
|
|
|
|
|
You can use SQLite. It is a free (public domain) database and it doesn't require an independent installation of a DB server.
It is also very simple to work with (you only need to reference its assembly) and it has reasonable free admin tools.
SQL Server Express is not really free. It has a size limit (4GB), it requires a separate installation (which makes installation more cumbersome) and it uses a separate server.
MySQL is not really free either (for commercial applications at least) and requires a separate installation of the DB server.
If you are interested - go to www.sqlite.org for more information. SQLite also has a very good .net provider (search on google).
Best of luck
Liron
|
|
|
|
|
download sql server 2005 free edition and also download the bob tubor free tutorial videos on microsoft.
nelsonpaixao@yahoo.com.br
|
|
|
|
|
I have a datasource that pulls a IP address. I need to call a function in SQL does the same as the asp class, that converts it to a non dotted format http://www.maxmind.com/app/csv[^]
which I can insert into my destination.
I tried using a lookup data flow item with SELECT [LogTracking].[dbo].[sfnConverIp] (?) but I can not map it to a column with the dotted IP.
There has to be a simple way right?
|
|
|
|
|
Hi,
I was having a discussion with someone much more knowledgeable than mysef about the data designer in VS2005 and I was just hoping to get his thought's on the topic. He was trying to tell me that it is very difficult to find the code for specific things. While I agreed with him, I noted that in almost all cases the code could be changed by using the designer itself, and that the features that were available such as click and drag databinding and the building of the dataset itself were very beneficial. Now I understand that the data designer is a shortcut to avoid writing code but at the end of the day I feel that we need to be more efficient and I know that a project that I am working on right now, I have saved about 1/2 the time by using the data designer. I would be really interested to see what people have to say on the topic.
|
|
|
|
|
Never used it, it's probably rubbish like any "shortcut to avoid writing code", pay attention to "someone much more knowledgeable than mysef".
There's no substitute for getting in there and really understanding what's going on.
|
|
|
|
|
Totally agree 
There should be a test in designers that after you can successfully write a solution using code, only then you are allowed to use graphical designer (or tool). I've seen so many total disasters after using a GUI without any knowledge what's happening behind the scenes 
|
|
|
|
|
Absolutely in agreement. If you look at how many questions are posted on CP where the real cause of the problem is lack of understanding....
Graphical designers should be banned for all non-GUI work - and before someone gets on their high horse, a well designed DAL means I can execute queries and return almost any type of result set (table, datareader, xml, collection etc) synchronously or asynchronously in about 5 lines of code.
Well, thats my opinion fo what is worth 
Bob
Ashfield Consultants Ltd
|
|
|
|
|
-
| |
-- --
|
--
|
--
|
--
-- |
---
That's supposed to be thumb up
|
|
|
|
|
and without a gui designer too
nice one
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Yeah, I didn't pass the test 
|
|
|
|
|
Well the data designer allows for data bindings in your gui with point and click action.
|
|
|
|
|
I wouldn't consider that any big advantage - its only a couple of line of code. I would consider an understanding of what happens in the background is far more important.
As I said originally, if you look at how many questions are posted on CP where the real cause of the problem is lack of understanding.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Have you used the Data Designer before? If so, what happened?
|
|
|
|
|
Yes I did try it, and spent many hours trying to make it fit in with OO principles and struggled to get it working with mutli-table transactions.
I now use a class generator that I wrote myself, which I just point at a stored proc and it will generate a class, or point it at a table and it will generate a class, and the stored procs for CRUD. It also generates a strongly typed collection for each class.
All in all I found it much more time consuming to use the gui data designer and trying to figure out work arounds for when it didn't do what I needed.
I suspect anyne who has been around since before .net is of the same opinion - at least they are where I am currently contracting.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
That's very valuable advice. Thanks a bunch.
|
|
|
|
|
Thats OK, you are welcome.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
After working extensively with visual studio 2005 data designer I came to the conclusion that it is evil. Don't use it if you can. I'd suggest using ORM packages like nhibernate to make mapping from DB to object oriented code more easy.
The problem is that VS data designer work at the table level. It simply maps a data table to a data class. This is a gross mistake because many times you have data that is scattered across many tables but is still owned (logically) by the same class. What happens next is that you have to work very hard to provide this mapping yourself.
Tools like nhibernate can help you alleviate this problem somewhat but now you have another headache to maintain (XML mapping files). Although I think this is better, it is still far from optimal.
The best solution IMHO is that we'll finally have a good, open-source and free (not GPL) object oriented database engine. With such a database you wouldn't need to handle these darn mapping issues at all.
Liron
|
|
|
|
|
Thank you for your reply by the way. You gave an honest critique of the data designer and it's drawbacks. I am having trouble understanding what you mean by mapping. Doesn't the DD provide it with your table relations that it pulls from your DB?
|
|
|
|
|
I'll give you an example from real life.
I have a Customer class that has a list of contact persons inside it. Something like:
public class Customer
{
public List<contactperson> Contacts;
}
This is a simple clean data class, but when you model it in the database you'll end up with two tables (of course this is just my interpretation - you can use different representation but this is a valid one in my case):
CREATE TABLE Customer
(
int CustomerID PRIMARY KEY,
nvarchar(50) FirstName NOT NULL,
nvarchar(50) LastName NOT NULL,
... more fields here
)
CREATE TABLE ContactPersons
(
int CustomerID, -- foreign key to the customer table
nvarchar(50) HomePhone,
.. more fields here
)
When you work with Visual Studio designer it will create a CustomerRow class and a ContactPersonsRow class to represent the rows of these two tables. However - you can forget about having it creating a single class like I showed you above. If you want such a class you'll have to write it yourself (relations will not help in this case).
Another problem is that the visual studio designer writes the autogenerated code around the concept of data sets and data tables. What do you do if you want to build a separate server process and than pass these objects between the client and the server? (you guess - more classes and more mapping code to map from data rows to your pure data classes and vice-versa). One of the tenets of good object oriented design is to separate the data classes from external DB specific interfaces (like ADO.NET) and Microsoft doesn't help at all in this regard.
All in all - the visual studio data designers are probably meant for building quick-n-dirty database solutions and not for providing the infra-structure that you need when building real-world applications. And I say this with a lot of grief because I'm currently stuck with their solution due to a bad decision on my part 
I don't even mention that there is no explicit support for retrieving data using both the CustomerTableAdapter class and the ContactTableAdapter class in the same transaction (you have to roll your own solution here because Microsoft did not think that such thing is common enough to warrant having it in their auto generated classes, another gross mistake IMHO).
In the end, you can either break object oriented encapsulation and go with Microsoft in their half-baked solution, use their designer generated code as a middle-ground for building real object oriented support to your data (my fate unfortunately) or use a mapping layer that will relieve you from having to write most of this code yourself (like NHibernate).
Personally I hate all of these solutions. For god sake we are in 2008 and there is no reason why we must use DB technologies from the 60s plus having to break our neck trying to interface with it. The relational DB model and the object oriented models are simply inconsistent with each other and a good, free object oriented database will solve the problem from its root.
In short - use Hibernate or something like it if you can. With regards to DB technology I sometimes feel like I came from the future and nobody knows what I'm talking about 
Good Luck
|
|
|
|
|
Firstly can't you code it yourself. I would see that relational problem as something that exists with our without the designer. Here is where I am coming from. There is no chance albeit poor design that I will require separation of processes. The reality is however that I end up saving a tremendous amount of time with the designer because while the anticipated amount of data will be small as far as rows are concerned, however I do plan on having an enormous amount of columns of data, and the designer seems to streamline that process. I believe that the best way would be to avoid the designer but when I have a client who is paying me by the hour and also really wants to see the app as they are in violation of the law without this app I am not so sure the correct decision is to hand code it. You know what I am saying??? As far as your idea of an object orientated DB, why wouldn't you just make objects, and then add them to a collection class, and then serialize the collection class. I started with such a model, but the code was up to 7000 lines of code and I decided that this wasn't the best way. I have however written programs in such a way and works well.
|
|
|
|
|
If you have a small number of tables and a simple data model + you don't need to handle client/server interactions or any of that stuff + the amount of data is small + you don't need transaction support or concurrent data access then using serialized data seems like a very good solution to me. I don't exactly know what caused this solution of yours to become a 7000 LOC monster but I bet that using the DB will grow you another one just as easily so be careful.
You may save time using VS data designers but only if you go with their solution and forget about object oriented encapsulation. It can work and it WILL save you time this way. If your application is small and your data requirements are simple it will work out just fine. However - if your application has a complex data schema and is expected to grow (in structure and/or data) than your attempt to save time will actually cost you more, a lot more (as I've already found in the hard way).
The reason that using serialized objects doesn't work in general is that it is not scalable for large amounts of data. You can't search according to specific fields when the data is serialized. You can't update the database every time a single property of some object changes. You can't handle concurrent access well and you don't have transaction support. If the file is small (<=1MB) this may work OK but it fails when the amount of data grows beyond this point due to excessive disk trashing etc.
Liron
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
