XML and the Datagrid

[solex]

Hello,
I am developing a small single user data entry/reporting application, and
was wondering if the approach of using XML with a schema and the datagrid
control is a valid approach or should I use a database instead? I do not
expect the total number of elements to be greater then 2500 rows.

Also, please point me in the direction of any sample applications on this
front.

Thanks,
Dan

[Cor]

Hi Dan,

This is so simple to do.

Open a project
Drag a datagrid to the form
Open and XSD file from the solution explorer
Add elements
Right to click make the dataset

Than this code
\\\
Dim dataset11 As New Dataset1
Private Sub Form1_Load(ByVal sender _
As Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.DataGrid1.DataSource = dataset11.Tables(0)
End Sub
Private Sub Form1_Closing(ByVal sender As Object, _
ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing
DirectCast(BindingContext(dataset11.Tables(0)),
CurrencyManager).EndCurrentEdit()
dataset11.WriteXml("c:\tester.xml")
End Sub
///
And your most simple solution is ready.

I hope this helps,

Cor

[solex]

Cor,

Thanks for responding.

I am familiar with the approach you stated, my question is using XML with
databound controls valid within the context of my specifications e.g. around
2500 rows of related data (4-5 tables), with reporting capabilities.

Dan
"Cor" <no*@non.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Hi Dan,

This is so simple to do.

Open a project
Drag a datagrid to the form
Open and XSD file from the solution explorer
Add elements
Right to click make the dataset

Than this code
\\\
Dim dataset11 As New Dataset1
Private Sub Form1_Load(ByVal sender _
As Object, ByVal e As System.EventArgs) Handles MyBase.Load
Me.DataGrid1.DataSource = dataset11.Tables(0)
End Sub
Private Sub Form1_Closing(ByVal sender As Object, _
ByVal e As System.ComponentModel.CancelEventArgs) Handles MyBase.Closing DirectCast(BindingContext(dataset11.Tables(0)),
CurrencyManager).EndCurrentEdit()
dataset11.WriteXml("c:\tester.xml")
End Sub
///
And your most simple solution is ready.

I hope this helps,

Cor

[Cor]

Hi Dan,

I thought that you would use this as a simple and small dataentry solution.

When it is really an application to hold data, than I think it is no good
solution.

My expirience is that it than very unstable.

Most of the time you are doing everything in memory, so when there is a
powerbreak you do lost everyting done till than.

When there is a write error you even can loose totaly everything if you do
not make the right procedures.

Just my thought about it.

Cor.

[solex]

Cor and Everyone,

In your experience then what good is XML, with the exception of applications
similar to Exchange Server (where each complex object is represented by a
single XML file) and as a means to transporting data.

Dan

"Cor" <no*@non.com> wrote in message
news:e8**************@TK2MSFTNGP11.phx.gbl...

Hi Dan,

I thought that you would use this as a simple and small dataentry solution.
When it is really an application to hold data, than I think it is no good
solution.

My expirience is that it than very unstable.

Most of the time you are doing everything in memory, so when there is a
powerbreak you do lost everyting done till than.

When there is a write error you even can loose totaly everything if you do
not make the right procedures.

Just my thought about it.

Cor.

[Cor]

Hi Solex,

I think I have had a time the same idea about XML as you.

However, it is to use as database nothing more than a very efficient text
file.
I find it, when it is in memory, exactly as good as the database, because it
uses the same procedures. In addition, when you do not use it as dataset,
you can even do more.

I wished that the complexity from an XML file was in a real database system.

The problem now is for me, that you cannot change items in an XML file while
it stays on disk. You have to read and write it streaming (although in one
time the whole file).

If you use it to get some data out the database, update it and write it back
as it is used now, it is in my opinion a good solution and also very good
usable in a web service where it is used as transport media for that data.

I can think on an option to make small XML files, which holds the data in
good organized small files as it done with some system information.

My problem is specially that when you are using it frequently and you have a
write error with a big XML file, while your recovery is not very well, you
are losing everything, you can make temporary files of course, but when you
use it very often, I think that will fail also.

It is in my opinion the best thing to describe and hold data until now and I
wished that the things I describe above were wrong. Than I get a total
different opinion about your question.

But just my thought about it today,

Cor

[solex]

Cor,

Thanks for input. I was coming to the same conclusion, the more involved I
got into the project, I am in the process of converting the XML file to a
series of database tables.

XML seems to provide a good data store specifcation when it is applied to
multiple XML files and exist on an application server that has a full-text
search engine.

Thanks Again!

Dan
"Cor" <no*@non.com> wrote in message
news:uF*************@TK2MSFTNGP12.phx.gbl...

Hi Solex,

I think I have had a time the same idea about XML as you.

However, it is to use as database nothing more than a very efficient text
file.
I find it, when it is in memory, exactly as good as the database, because it uses the same procedures. In addition, when you do not use it as dataset,
you can even do more.

I wished that the complexity from an XML file was in a real database system.
The problem now is for me, that you cannot change items in an XML file while it stays on disk. You have to read and write it streaming (although in one time the whole file).

If you use it to get some data out the database, update it and write it back as it is used now, it is in my opinion a good solution and also very good
usable in a web service where it is used as transport media for that data.

I can think on an option to make small XML files, which holds the data in
good organized small files as it done with some system information.

My problem is specially that when you are using it frequently and you have a write error with a big XML file, while your recovery is not very well, you
are losing everything, you can make temporary files of course, but when you use it very often, I think that will fail also.

It is in my opinion the best thing to describe and hold data until now and I wished that the things I describe above were wrong. Than I get a total
different opinion about your question.

But just my thought about it today,

Cor