|
Well there are like thousands of articles and blog entries on the internet, and probably some on this site about storing blobs in databases.
ASP.NET has a control in the Visual Studio Toolbox for uploading files. I would bet like a cup of coffee that Microsoft has hidden some sample code for using it in the documentation of the control, sneaky bastards!
led mike
|
|
|
|
|
I am sure there are a ton of examples of implementing the control but the trick is which control. Which is the best fit for what I am needing to do?
i.e. allow users to browse for a .pdf, then take that .pdf and insert it into a mySQL database.
Is it openfiledialog ???
The answer you gave could work for any question. Go read the documentation is basically all you said.
Thanks!
|
|
|
|
|
Derrick.greer wrote: Is it openfiledialog ???
Well I may be confused at this point. Your first post said:
Derrick.greer wrote: This application should allow the users to upload a .pdf file
"Uploading Files" is generally used to discuss client server file transfer of the file. I therefore assumed you were doing an ASP.NET Web application. So perhaps you could define your project to clear this up?
led mike
|
|
|
|
|
Here is what I would like to do.
1)I would like the application to allow the user to browse for a .pdf file.
2)I would then like to take that selected file and insert it into a mySQL table.
I was able to get the browse functionality working using the OpenfileDialog but i do not know where to go from there. I basically have a path to the file but nothing else.
Sorry for the confusion that my post caused and thank you for your help.
|
|
|
|
|
So this is a Windows Forms application, a desktop application?
Derrick.greer wrote: 2)I would then like to take that selected file and insert it into a mySQL table.
Where is this database? Is it on the same machine? How are database connections created?
As I said in my first post there are tons of database articles right here on CodeProject for storing blobs in Databases.
If it takes more than 3 posts for you to provide adequate information about your project requirements/architecture that pertain to your questions I will have lost all interest in helping you.
led mike
|
|
|
|
|
Derrick.greer wrote: The answer you gave could work for any question. Go read the documentation is basically all you said.
It's generally very good advice. You'd be surprised at how many questions we answer where the poster could have answered it themself with a 2 minute session reading the manuals.
|
|
|
|
|
led mike wrote: sneaky bastards!
yeah, they're like that! 
Dave
|
|
|
|
|
Hey Guys,
Maybe I'm missing something. I thought you could set the ListView where the user can drag items from WITHIN and drop them into other items. The only thing I've been able to do drag objects from without the listview. The functionality should be indentical to a structure like: "My Documents".
Can anybody give a heads up on how to implement this feature?
Thanks
Richard
If you could rent a programmer a hour and a half for a dollar and a half, how much would he charge for 10 hours?
|
|
|
|
|
programmingAddict wrote: I thought you could set the ListView
Are you working through a sample or tutorial? Which one?
If not, you should be as well as using the documentation for ListView of course.
led mike
|
|
|
|
|
I have read that using the registry is out and one should use XML files for storing configuration data on an application.
By using the registry I can hide and prevent the deletion of configuration data - so what is the advantage of using XML in this case, other than learning how to code XML file structures?
My question is really more a case of why use XML in this instance as opposed to the registry?
I ask this a a complete ignoramus in the area of XML
You always pass failure on the way to success.
modified on Tuesday, March 4, 2008 3:07 PM
|
|
|
|
|
GuyThiebaut wrote: By using the registry I can hide and prevent the deletion of configuration data
Really? How do you do that?
led mike
|
|
|
|
|
Okay - let's put it this way, an XML file sitting in the the application folder can be deleted by deleting the folder.
By storing data in the registry the average user of my product, who will probably not even know what the registry is, is only likely to delete the registry entries if they cover their machine in napalm and fire a cruise missile at it. 
You always pass failure on the way to success.
modified on Tuesday, March 4, 2008 3:06 PM
|
|
|
|
|
Well I'm certainly not going to argue with that logic so I suggest you just forget about XML and use the registry. You might even consider removing the 'X' 'M' and 'L' keys from your keyboard.
led mike
|
|
|
|
|
Thanks.
Have a nice day 
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: in the the application folder
Then don't put it there. I use
C:\Documents and Settings\All Users\Application Data
or similar to hold such things. You can even set the Hidden attribute if you like. I have found that the file remains even after an uninstall of the app.
|
|
|
|
|
The registry can be edited just as easily (probably easier to the general user because of it's tree structure) as an xml file.
In case of a hard drive/OS failure, it's pretty diffucult, and sometimes impossible, to retrieve data from the registry, but because an xml file is local, it's easy to get access to for restoration purposes.
If your app is ever used on Vista, the registry works differently from previous windows versions (unless you want to bother your users with UAC prompts everytime they launch it), so it's not guarenteed to have consistant data across users even if storing in HKLM.
My advice is XML in System.Environment.SpecialFolder.CommonApplicationData + "/YourAppName/"
Dave
|
|
|
|
|
Thanks
This helps me make sense of why XML is a better choice.
Part of me was feeling like it was a step back to the good old days of ini files.
I think I will put in the small amount of effort to learn XML (it's an extra skill learned).
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: I think I will put in the small amount of effort to learn XML (it's an extra skill learned).
While you're doing it, check out the System.Xml.Linq namespace. Most of the examples around use System.Xml but the newer stuff is pretty cool, much simpler and more powerful once you get used to it. Combining the two (XmlDocument and XDocument for example) isn't always that easy so sticking with the one namespace to begin with is a good idea.
Dave
|
|
|
|
|
DaveyM69 wrote: check out the System.Xml.Linq namespace
Thanks Dave
Will do.
You always pass failure on the way to success.
|
|
|
|
|
The theory is twofold
1 - because uninstallers do not remove registry entries, a clogged registry is one reason windows slows down with time
2 - an XML file means you can copy a folder to another machine and the app will just work
XML is just a way to give order to a text file, it's rules for parsing are standardised, but at the end of the day, it's not that different to using an .ini file. But, a clueless user who tries to edit XML, is more likely to make the file invalid, which will hinder them from doing it. But, most users who would be willing to edit an XML file, are likely to know what the registry is.
I use XML now because I agree that the registry has become a crowded neighbourhood, and that this causes users grief in the long run.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Christian Graus wrote: XML is just a way to give order to a text file, it's rules for parsing are standardised, but at the end of the day, it's not that different to using an .ini file. But, a clueless user who tries to edit XML, is more likely to make the file invalid, which will hinder them from doing it. But, most users who would be willing to edit an XML file, are likely to know what the registry is.
I 100% agree with this and if the original poster is so worried about a user editing the XML, he could just Base64 encode all the elements, attributes, and values. That way the user would have no idea what changing it would do and therefor be more inclined to just ignore the XML file.
|
|
|
|
|
Yeah, I have encrypted values I don't want the user to mess with before.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks - these replies have certainly helped to change my view - XML here I come 
You always pass failure on the way to success.
|
|
|
|
|
Thanks - I will take your advice on it being best in the long run.
You always pass failure on the way to success.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
