|
LiquidE_SA wrote: The product I'm developing is a product that will be sold to alot of different people. It will aid them in doing some basic stuff. Therefore I need a method/way of handling the database, wihtout installing extra servers/software.
How much data?
LiquidE_SA wrote: The thing as I understand it with SQL Server I'll need to install it on every machine
Well, no. As the name suggests it is a "server" product. So, it is installed once on a server (in large organisations they may have many SQL Servers to spread the load)
LiquidE_SA wrote: That will cost alot of money, won't it?
SQL Server 2005 Express Edition is free - but it has some restrictions (but not as limited as Access)
LiquidE_SA wrote: I need something that I can bundle with the application.
SQLLite or VistaDB may be choices - but you still need to answer the question "How much data?"
Some companies make products that are specifically designed to sit on top of SQL Server. Perhaps you can do that. If you are marketing to small businesses they may already have Microsoft Small Business Server which has SQL Server built in. When that company grows they can migrate to a full SQL Server easily.
So far, I don't think you've provided enough information to say which database is a good choice. How does the application interact between users? Is it even multiuser?
LiquidE_SA wrote: Isn't there methods of doing datafile handling and data integrity chechs from within C#?
You can do that in C# if you want - but do you really want to be reinventing the wheel?
|
|
|
|
|
No thanks. No reinventing the wheel here.
No, the application is not even multiuser. It's a small application that will help others start their own company. It won't need to store alot of data. Maybe 20/30MB of data, if it's that much!
Are SQLLite and VistaDB also running on a server or can it be accessed by file such as Access?
ASBESTOS-Greetings
LiquidE
|
|
|
|
|
LiquidE_SA wrote: Are SQLLite and VistaDB also running on a server or can it be accessed by file such as Access?
I think your choice is now between SQLite[^] and VistaDB[^]. Both are file based databases.
Both are effectively zero configuration for the end user. You just drop one (or two) additional DLL files in to your installation and you are good to go.
SQLite:
* You'll also need a .NET Wrapper for SQLite (but that's explained on the website and is very easy to set up).
* Because SQLite is supported in so many environments the documentation can take a little getting used to.
* It is free
VistaDB
* Pure .NET solution
* Costs money for a development license.
* Also has a server based solution if you eventually decide you need to scale up.
|
|
|
|
|
Thank you VERY much. You've been of great help.
Enjoy the rest of your day.
ASBESTOS-Greetings
LiquidE
|
|
|
|
|
|
There is also SQL Server 2005 Everywhere Edition[^](also called SQL Mobile) which is also a file based database that allows you to scale up to (and integrate with) SQL Server 2005 when necessary.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
You can add a version of MSDE with the installion of your app.
MSDE is a free but limited download from MS.
Research it alittle sounds like a good solution for you.
But MSDE and SQL 2000 will not be supported by Vista or Longhorn.
|
|
|
|
|
I realize that readonly or writeonly properties can't work, but shouldn't a check for the ability to do both be doable at compile time?
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Because a read/write property will also not work.
What it is doing is passing in a reference to a value or object, not a reference to a property. If you want to pass a reference to a property you might find that delegates work for you (but I've not tried).
|
|
|
|
|
Colin Angus Mackay wrote: If you want to pass a reference to a property you might find that delegates work for you (but I've not tried).
What do you mean by that, Colin? I don't understand as delegates can't be used on properties.
|
|
|
|
|
Judah Himango wrote: What do you mean by that, Colin?
Really? Okay - I knew that properties were just syntactic sugar for a getter and setter method so I thought you might be able to use delegates. Note my disclaimer "but I've not tried". 
|
|
|
|
|
Yeah, it's a real shame you cannot use a delegate over a property. I often use delegates to give me the names of methods used in unit testing:
viewMock.Expect(ViewCloseMethodName);
...
string ViewCloseMethodName
{
get { return new Function(this.view.Close).Method.Name; }
}
Sadly this doesn't work for properties, meaning my unit testing mocks are prone to failure if I happen to rename a property. 
|
|
|
|
|
Judah Himango wrote: I don't understand as delegates can't be used on properties.
You can work around that using reflection, but the end result is really ugly.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
I'm actually looking for a way get the string name of a property through code. I have the property sitting there typed, i.e.
IFoo someType;
someType.SomeProperty;
Is there a way to get the string name of the property? Obviously I can just do string propName = "SomeProperty", but that instantly breaks the moment I change the name of the property.
|
|
|
|
|
Judah Himango wrote:
Is there a way to get the string name of the property? Obviously I can just do string propName = "SomeProperty", but that instantly breaks the moment I change the name of the property.
AFAIK no. I was trying to find that capabilty unsuccessfully in my decent into delegate hell.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Too bad they don't let us access the get_ and set_ methods directly. I'd really like to be able to do this:
ThreadStart ts = get_Prop;
string Prop
{
get { ... }
}
|
|
|
|
|
Same here.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
using System.Reflection;
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(this.GetPropertyName(typeof(MyTestClass),3));
}
private string GetPropertyName(Type myType, int nPropToGet)
{
int nPropCounter = 0;
foreach (PropertyInfo pi in myType.GetProperties())
{
nPropCounter+=1;
if (nPropCounter == nPropToGet)
return pi.Name;
}
return null;
}
-- modified at 18:04 Tuesday 21st November, 2006
--EricDV Sig---------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
Eric, it's true that would solve the string-based reflection problem. However, it would introduce a different problem which is even more severe than the string-based reflection problem, right? I mean, if I add a new property to my class, this solution would break because the property index would change.
Really what I'm looking for is getting the name of a property when I actually have access to the property.
view.SomeProperty.Name
Or something a little more delegate-oriented:
new Function(view.set_SomeProperty).Method.Name
either would suffice just fine! Seems really odd we cannot do this. If you use unit testing with mock objects, you'll find this is in your face the whole time: you'll say something like:
myMockView.Expect("set_MyProperty");
If I or another dev comes along and renames the property, the unit test breaks. 
|
|
|
|
|
I've never done unit testing, and I'm new to C#. I'm studying reflection right now, and I'm a bit surprised that I can't seem to find a way to get PropertyInfo for a property directly (as you mentioned). I feel like I must be missing something...but I'll defer to your experience.
--EricDV Sig---------
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
- Laurence J. Peters
|
|
|
|
|
There is one possibility I see: if you're inside the property, one could do MethodInfo.GetCurrentMethod() to retrieve the method while inside the getter or setter of the property. Outside of that, there's no way I see that doesn't rely on either string-based reflection or index-based reflection, both of which have problems when modifying existing code.
|
|
|
|
|
It would be possible to implement in the language, but I don't think that there are so many that are interrested in developing it in that direction.
Using out/ref parameters is the old, procedural, way of handling data. Properties is the new, object oriented, way of handling data.
Also, if it was implemented, it would implicitly use a temporary variable anyway, so there is no real gain. On the contrary, it would hide what's actually going on, probably causing quite some confusion along the way.
If I for example have a property that will display it's value on the screen, and I send that property to a method using ref, you could expect that every time the method changes the value, the property would change and the value would be displayed on the screen. That is of course not so, as the method only would be changing the temporary variable, and the property would only be changed after the method returns.
---
b { font-weight: normal; }
|
|
|
|
|
the current situation can result in really ugly code though.
dataobject.someProperty = formObject.recomputeValue(dataobject.someProperty, otherValue1, otherValue2, ...);
or
<br />
int temp = dataobject.someProperty;<br />
formObject.recomputeValue(out temp, otherValue1, otherValue2, ...);<br />
dataobject.someProperty = temp;<br />
vs
formObject.recomputeValue(out dataobject.someProperty, otherValue1, otherValue2, ...);
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
dan neely wrote: the current situation can result in really ugly code though.
dataobject.someProperty = formObject.recomputeValue(dataobject.someProperty, otherValue1, otherValue2, ...);
Why do you think that the code is ugly? If the method returns a value, the return value is a good place to put it.
dan neely wrote: or
int temp = dataobject.someProperty;
formObject.recomputeValue(out temp, otherValue1, otherValue2, ...);
dataobject.someProperty = temp;
That should actually be:
int temp;<br />
formObject.recomputeValue(out temp, otherValue1, otherValue2, ...);<br />
dataobject.someProperty = temp;
There is no reason to assign anything to a variable that is going to be used as an out parameter.
Using out/ref parameter and properties are two completely different approaches, so it's not at all a bad thing that they are separate in the code.
dan neely wrote: vs
formObject.recomputeValue(out dataobject.someProperty, otherValue1, otherValue2, ...);
If that would be allowed, it would be implemented exactly as the code with the temporary variable, with the only exception that the the temporary variable doesn't have a name.
Allowing properties as out parameters would only serve to hide what's actually going on. In a language like VB that might be desired, but hardly in C#.
Shorter code is not always better code.
---
b { font-weight: normal; }
|
|
|
|
|
Guffa wrote:
Why do you think that the code is ugly? If the method returns a value, the return value is a good place to put it.
Because langague limitations are forcing me to stuff a parameter in two locations, not just one.
Guffa wrote: That should actually be:
Actually it should've been:
int temp;<br />
formObject.recomputeValue(ref temp, otherValue1, otherValue2, ...);<br />
dataobject.someProperty = temp;
In this case the recompute does depend on the original value.
Guffa wrote: If that would be allowed, it would be implemented exactly as the code with the temporary variable, with the only exception that the the temporary variable doesn't have a name.
Allowing properties as out parameters would only serve to hide what's actually going on. In a language like VB that might be desired, but hardly in C#.
Shorter code is not always better code.
The intent of properties is to wrap the datahiding and validation of get/set methods, and allow them to be used like a public variable. This is the most severe failing of the itent. Having used property names and reflection to work around the limitation once before in a major code block, if i have to do it again, I'll be using public data members instead.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
