|
I suggest that you are only updating the values in your table adapter but the table adapter does not store the data into the database - the data stays in the memory (table adapter). There must be a method to force the table adapter to update the database - Don't ask me how it is called exactly but you might want to have a look into the corresponding MSDN article[^].
|
|
|
|
|
i had a look on it,and tried update(database),and update(datatable) but it does not work.when i look to my database after mofication ,i don't find the new entry.
|
|
|
|
|
Is youre database file-based, like Access?
If so, are you copying the balnk database from your project to the bin folder every time you build?? This is usually the case when an Access database is used and is part of the project as a Content file. These files are recopied to the build bin folders every time you recompile the project, thereby overwriting the data your wrote in the last pass.
|
|
|
|
|
i create a database using visual studio .mdf
|
|
|
|
|
As Dave said, it is quite possible that your .mdf file is being recopied from your source directory to your bin directory when you rebuild your project. Check the properties of the file in Visual Studio and make sure Copy is not set to "Copy always". You should also check the code where you do the Insert or Update commands.
Use the best guess
|
|
|
|
|
Hi,
I know the functionality of Abstract Class & Interface.
But, in which situation i can use this.
Consider I am starting a new project and I need to design and create a class. So here in which situation I should create AbstractClass or Interface. How to find out which is suitable for particular situation.
Please give me some practical situation where I can use and where I can't.
krishna
|
|
|
|
|
If you need the actual implementation of some functionality to be the same, you would consider an abstract class. If you only need the contract to be the same or you need to do something that looks like multiple inheritance, use interfaces.
|
|
|
|
|
Hi Mr.Pete
Even I can use Interface for the common functionality, correct me if I am wrong.
krishna
|
|
|
|
|
Sorry to steal Pete's thunder.
You can't use an interface for the implementation of common functionality, all an interface does is define what is available not how it is actually achieved. Lets take a simple example, modelling a cats which can for simplicity only look around or make a noise the Interface would look like:
public interface IFeline
{
LookAround();
MakeNoise();
}
OK, lets say I want to model a Tiger and a Cat. Both Implement IFeline, both look around in the same way, but a cat purrs but a Tiger roars. LookAround is common to both and should be in a base class. I don't ever want to create and instance of the base class, so I create an abstract one which encapsulate what is common:
public abstract class Feline: IFeline
{
public LookAround()
{
Console.WriteLine("Looking");
}
public abstract MakeNoise();
}
Now I can implement the differing functionality:
public class Cat: Feline
{
public MakeNoise()
{
Console.WriteLine("Purrr");
}
}
public class Tiger: Feline
{
public MakeNoise()
{
Console.WriteLine("Roar");
}
}
Hope this helps!
|
|
|
|
|
Hi,
Mr.Keith I really love you, such a sweet example which opens my eyes. I clear about the abstract class now.
But, why I should't use like below code ??
public class Cat: Ifeline
{
public MakeNoise()
{
Console.WriteLine("Purrr");
}
public LookAround()
{
Console.WriteLine("Looking");
}
}
public class Tiger: Ifeline
{
public MakeNoise()
{
Console.WriteLine("Roar");
}
public LookAround()
{
Console.WriteLine("Looking");
}
}
krishna
|
|
|
|
|
Your code would work, but you have repeated LookAround() method, this increase your maintenance overhead if you needed to change one, the chances are you'd need to change the other. Obviously this is a simple example to try and make the principle clear so it doesn't stand up to close scrutiny. Additionally the abstract class adds a semantic meaning : these are all the things that my subclasses can do that are common to all of them.
|
|
|
|
|
Thanks a lot keith, really appreciate your effort to make me understand 
krishna
|
|
|
|
|
|
An example of where I have used an interface and abstract class:
I created a print interface.
I implemented the general features through an abstract class(add line, print document etc).
I then inherited from this abstract class for printing from a datagrid or datatable(remember you cannot instantiate from an abstract class).
These classes then override, when needed, the methods in the abstract class.
This way I can extend the abstract class to print from pretty much anything I want.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Hi Mr. Chistopher
In the same way I can create Interface with( add, print method etc).
I then Implement this Interface so that I can print from datagrid or datatable.
Correct me if I am wrong.
krishna
|
|
|
|
|
You are correct, although I am not Mr Christopher I am Mr Guy 
The interface declares the methods you will be implementing such as print, add line, page header, page footer etc.
The abstract class then implements these methods but cannot be instantiated - so you then create classes that use the abstract class as their base class overriding the add line etc methods.
Does that make sense to you?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 8-Mar-13 9:41am.
|
|
|
|
|
Mr. Guy,
I am very much clear about what you said. Now I have another doubt, Is that any rules that abstract class must inherit interface, than we need to override from abstract class ?
I can create a normal class which can implement this Interface and use those methods. But here we have to create instance of the class to access those implemented methods.
So overall you mean to say that, one of the reason to go for abstract class to avoid creating instance of the class ?
krishna
|
|
|
|
|
Hi Krishna,
Please just call me Guy as Mr Guy is too formal for the codeproject
An abstract class does not need to implement an interface.
An abstract class must be inherited as you cannot create an instance of an abstract class - think of an abstract class as something like a Feline, in Keith's excellent illustration, which is a concept and for which there is no such concrete existence.
However there are tigers which are Feline and are very much concrete - so a tiger inherits from the abstract class of Feline.
You can just create an abstract class and then inherit from that class to create your instances(without implementing an interface).
An abstract class allows you to implement some very general methods such as the LookAround method in Keith's illustration which will not need to be overridden.
Abstract classes are a means of writing less code and implementing polymorphism.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Explained very well, thanks a lot guy..
krishna
|
|
|
|
|
Let it evolve as you develop it. Don't force it.
|
|
|
|
|
Abstract class and inheritance is all about building a hierarchy (or family) of classes while Interface is to enforce a contract.
Consider this hierarchy of classes. You can create FlyingVehicle as an abstract class.
Vehicle --> FlyingVehicle --> Helicopter
Consider another hierarchy of classes. You can create Bird as an abstract class.
Animal --> Bird --> Eagle
While the two families of classes are distinct, both the the FlyingVehicle and the Bird classes can implement an Interface called IFlyable.
interface IFlyable {
void Fly();
void Land();
}
As you can see in this example, you created two distinct families of classes using Abstract classes and enforced the ability to fly using an interface.
|
|
|
|
|
Mr.Shameel,
Can you please make those example's little clear, mean to say.. describing interface & abstract class with the same example by inheriting.
krishna
|
|
|
|
|
That's the point here, abstract classes and interfaces are not meant to be used interchangeably (although most programming languages allow you to do that). Classes are to build family and interfaces are to enforce contracts, nothing more, nothing less.
|
|
|
|
|
|
krishnavaradharajan wrote: I know the functionality of Abstract Class & Interface.
Normally the "functionality" has nothing to do with the decision.
You use them because they meet the design needs.
krishnavaradharajan wrote: How to find out which is suitable for particular situation.
1. Collect some requirements.
2. Create a design.
3. Use the design to implement code.
Step 3 is where you decide which one to use based on the objects of the design.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
