I have to update the XML <Amount> to False when I use the value. Do I have to worry about multiple concurrent users requesting for the file or can someone point to a better approach? I don't want the application to crash. I thought I could use an mdf file
but not for deployment and now I'm concern with the application crashing with multiple users. Any help is much appreciated.
We have to distribute the application to our client and we can't add/modify any SQL Table or StoreProc. Moving forward, instead of creating windows applications we are developing small web apps. Easier to maintain and deploy. I'm new to using XML as a source
of data and I want to make sure the application does not crash.
We may have 2-5 concurrent users at any given time(maybe ). It won't be a high traffic application and the XML file
may contain less than 1000 records as the example above. Would that be a good approach?
Traditionally, in web development, XML is used as a vehicle to move data around not a datastore. In stand-alone winforms development, yes, XML as a datasource is fine as long as the data isn't shared.
It sounds as if the XML data will be shared among more than 1 user in a web environment correct? That will be difficult to maintain considering you're at the mercy of a file based locking system...meaning if the file is open, it's locked. That's going to
be painful to workaround.
My suggestion would be to use SQLCE which will handle those transactions for you and designed to be easily distributable.
Marked as answer by mitoy75 on Apr 27, 2012 04:40 PM
mitoy75
Member
200 Points
136 Posts
use XML file as source for data, do I have to worry about lock the file?
Apr 25, 2012 02:42 PM|LINK
Hello everyone!
I'm going to use an XML file as a source for a list with about 1000 records. The XML file will look something like this:
I have to update the XML <Amount> to False when I use the value. Do I have to worry about multiple concurrent users requesting for the file or can someone point to a better approach? I don't want the application to crash. I thought I could use an mdf file but not for deployment and now I'm concern with the application crashing with multiple users. Any help is much appreciated.
adamturner34
Contributor
3938 Points
995 Posts
Re: use XML file as source for data, do I have to worry about lock the file?
Apr 25, 2012 02:46 PM|LINK
Why can't you use SQL Server which will handle the transactions for you?
mitoy75
Member
200 Points
136 Posts
Re: use XML file as source for data, do I have to worry about lock the file?
Apr 25, 2012 03:46 PM|LINK
We have to distribute the application to our client and we can't add/modify any SQL Table or StoreProc. Moving forward, instead of creating windows applications we are developing small web apps. Easier to maintain and deploy. I'm new to using XML as a source of data and I want to make sure the application does not crash.
We may have 2-5 concurrent users at any given time(maybe
). It won't be a high traffic application and the XML file
may contain less than 1000 records as the example above. Would that be a good approach?
I'm open for suggestions, as I can't use SQL.
Thanks!
adamturner34
Contributor
3938 Points
995 Posts
Re: use XML file as source for data, do I have to worry about lock the file?
Apr 25, 2012 05:48 PM|LINK
Traditionally, in web development, XML is used as a vehicle to move data around not a datastore. In stand-alone winforms development, yes, XML as a datasource is fine as long as the data isn't shared.
It sounds as if the XML data will be shared among more than 1 user in a web environment correct? That will be difficult to maintain considering you're at the mercy of a file based locking system...meaning if the file is open, it's locked. That's going to be painful to workaround.
My suggestion would be to use SQLCE which will handle those transactions for you and designed to be easily distributable.
mitoy75
Member
200 Points
136 Posts
Re: use XML file as source for data, do I have to worry about lock the file?
Apr 26, 2012 12:07 AM|LINK
Thanks for pointing that out, I will take the time to read it tonight.