|
You cannot use Convert.ToString to get an image; and why would you? The Value method returns an object, so you just need to cast it to the correct type.
Use the best guess
|
|
|
|
|
Actually I do not avia realized it, the more I've sure could do with that format! was a mistake to send the code so ...
|
|
|
|
|
I store almost all of my data for my applications in xml-files. Works fine, especially with Linq-Support
But I continuously ask myself, if it is not better to store data in a database (SqlExpress or MySql) with much advanced data-handling-capabilities
One advantage of xml is, that files can be easily moved around via simple copy/paste. Do I loose this feature with a database?
modified 26-Apr-13 14:05pm.
|
|
|
|
|
It's more to do with what you're doing with the data that should determine this. Also, XML is not a database, though too many noobs treat it like it is one.
If you're not doing any reporting or anything that requires shared access to the data, you're probably fine with XML.
You can move it to a database, but you make it harder to move the files around. You can attach and detach database files, but it may not be as easily as just a straight XML file depending on the database engine you chose.
|
|
|
|
|
Thank you for your answer
I continuously see some code-examples, where a database-table is bound to some control and data are displayed in any control almost "magically". Is this also possible with xml?
|
|
|
|
|
You can't bind a database table to a control.
You bind the control to any object that implements (If I remember correctly) IList, IListSource, IBindingList, or IBindingListView. This includes, but is not limited to, any one dimensional array, any collection (i.e.: List, List<t>), DataSet, DataTable, DataView, BindingList<t>, BindingSource, ...
You can put your database data into any suitable object and bind the grid to it.
|
|
|
|
|
Features are never loose with a database, they are always tight.
Your "advantage" that you say with XML is actually a problem if you are talking about shared data. The problem is User 1 edits some data and sends it to User 2 - then User 2 edits some data and sends it to User 3 - at this point, User 1 has WRONG DATA, because they are still holding an old copy of the file and they have no way of knowing that User2 made changes. So, as a general rule, any data which will be used by multiple users needs to be in a database. Well, it needs to be in a central location that everyone is using - so it could be an XML file on the network, right?
Your problem here isn't about the technology being used to store the data, the issues you need to solve are about how the data is used. Files can cause major problems if the data is used by multiple users, while databases are specifically designed for that situation. Many companies have an internal problem knowing what the truth is about the company, because they don't all pull their data from a central source. Don't be like that.
On the other hand, users love files! They like to have control over 'their' data and when it's in a file on their machine, they feel comfortable with that. This is good practice for data that is work product, such as images produced by graphic designers, or engineering drawings from AutoCad, things like that. They control it while they want to, and they control how that information is shared. If you need user-level control like that, staying with files might be more appropriate.
|
|
|
|
|
Jasmine2501 wrote: Features are never loose with a database, they are always tight.
That isn't true - using your definition.
It is a common problem that an update to a database does not instantly appear in all clients. So one must account for that. Usually by just ignoring it because actual business cases (not hypothetical development cases) do not allow for it.
Jasmine2501 wrote: Many companies have an internal problem knowing what the truth is about the company, because they don't all pull their data from a central source
Which of course isn't solved by technology but rather architecture (people).
|
|
|
|
|
You missed the joke, and the heinous spelling error.
Your pants can be loose. Your database can't.
|
|
|
|
|
Jasmine2501 wrote: You missed the joke
So you are stating that your entire posting was a joke?
|
|
|
|
|
No just the part you didn't get.
|
|
|
|
|
Jasmine2501 wrote:
No just the part you didn't get.
I responded to the entire posting - and it was incorrect as I stated.
|
|
|
|
|
Stop it, you're making yourself look bad. The joke is obvious, I even bolded it.
|
|
|
|
|
Jasmine2501 wrote: Stop it, you're making yourself look bad
You are making assumptions about me.
Jasmine2501 wrote: The joke is obvious, I even bolded it.
As I already said - I was responding to your entire post. And as I said, it was wrong.
|
|
|
|
|
jschell wrote: As I already said - I was responding to your entire post. And as I said, it was wrong.
No it's not. There is nothing wrong about my post. Everything I said was 100% true, and backed by 25 years of experience in this industry. There was a joke about horrible spelling in there, and that wasn't wrong or right, it was funny if you got it, which you didn't. The fact that you responded to that was funny for a minute but now it's just lame.
http://dictionary.reference.com/browse/loose?s=t[^]
http://dictionary.reference.com/browse/lose?s=t[^]
Get it now?
|
|
|
|
|
Jasmine2501 wrote: Everything I said was 100% true,
My original post explained why it was wrong. If you didn't understand that you should have asked.
Jasmine2501 wrote: and backed by 25 years of experience in this industry
I have that beat.
Jasmine2501 wrote: it was funny if you got it, which you didn't.
And you obviously keep ignoring that I was responding to you entire post despite me stating it explicitly multiple times. Your continued restatement that you were attempting to be funny will not change that nor does it alter what I said.
|
|
|
|
|
I said "features are never loose with a database, they are always tight" which was a joke on the mistaking of "loose" for "lose" and you responded as if it was a serious statement. That was your mistake, and this lame attempt to defend yourself is only pointing out the fact that you missed the joke. Now stop it, you're embarrassing yourself.
Secondly, even if your response was not about the part you quoted, but also about the rest of what I said, that particular response didn't make a whole lot of sense and I disagree with it, based on my many years of experience in the real business world, which is more like 30 years, but it isn't a competition. I have enough experience to know that what I said is absolutely true almost anywhere you go and if you disagree with it, that's fine, I will leave it to the readers to decide for themselves.
|
|
|
|
|
Jasmine2501 wrote: I said "features are never loose with a database, they are always tight" which was a joke on the mistaking of "loose" for "lose" and you responded as if it was a serious statement. That was your mistake, and this lame attempt to defend yourself is only pointing out the fact that you missed the joke. Now stop it, you're embarrassing yourself.
I suggest you re-read the sub thread. Pay particular attention to where I told you repeatedly that I was responding to your entire post.
Jasmine2501 wrote: based on my many years of experience in the real business world,
Since it isn't possible to instantaneously update all clients I can't imagine what business experience you have had.
|
|
|
|
|
jschell wrote: I suggest you re-read the sub thread. Pay particular attention to where I told you repeatedly that I was responding to your entire post.
I already addressed that problem.
jschell wrote: Since it isn't possible to instantaneously update all clients I can't imagine what business experience you have had.
I did not say it was.
This is really annoying. If you're trying to annoy me, it's working. If you're trying to disprove something I said, that's not working.
|
|
|
|
|
Jasmine2501 wrote: If you're trying to annoy me, it's working
I am pointing out an incorrect statement. Your emotional state has nothing to do with it.
Jasmine2501 wrote: If you're trying to disprove something I said, that's not working.
I don't need to disprove it since you already agreed that one can't update all clients immediately.
Not with an xml file and not with a database. You claime the former and ignored the latter.
|
|
|
|
|
jschell wrote: I am pointing out an incorrect statement. Your emotional state has nothing to do with it.
It is absolutely correct and you are wrong, and that is absolutely annoying and it would be to anyone. Seriously, let it go dude, nobody cares any more.
|
|
|
|
|
Jasmine2501 wrote: It is absolutely correct and you are wrong
You are wrong.
Jasmine2501 wrote: and that is absolutely annoying and it would be to anyone
Again that is an emotional context which doesn't interest me and has nothing to do with the technical merits.
Jasmine2501 wrote: Seriously, let it go dude, nobody cares any more.
And yet you keep responding and keep claiming that I am wrong.
|
|
|
|
|
Strictly from the database side of the equation I'd vouch for the use of xml stored in the database as xml almost solely on the ease of using one table to stack all the individual "xml" up. It's sort of a side-effect that turns out to be exceedingly useful.
Isn't this the reason there are TABLE in SQL? And not FILE?
modified 27-Apr-13 16:24pm.
|
|
|
|
|
RedDK wrote: Isn't this the reason there are TABLE in SQL? And not FILE?
In Paradox, those concepts were the same.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Frygreen wrote: One advantage of xml is, that files can be easily moved around via simple copy/paste. Do I loose this feature with a database?
Depends what database-system you'll be choosing. For local data, I prefer SQLite (over SqlCE) as it's available on both Windows and Linux. One can XCopy such a file-database if no-one is using it at that particular moment.
SqlExpress or MySQL would be recommended if your user wanted to share his/her data.
A huge advantage of using a database over a custom structure is the fact that a database has been built for the explicit reason of storing data, and has been optimized over years to do so. It'd be faster, more secure, and it'd cut the dependency to the custom structure (iow, it'd be "standardizing" on Sql).
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
