Actually, a Jet database (.mdb file, which Access uses) doesn't require Microsoft Access at all. It simply uses the Microsoft Jet database engine that should be installed when you install MDAC 2.6 or higher, which is required for ADO.NET anyway. I might be wrong and it might be a separate download (they keep changing all that), but it'll be small and probably already installed because a lot of stuff uses it. That's probably the best database file you could use. With technologies behind it like DDL, you can even create a database from scratch, although shipping a .mdb file with a schema already created would probably be easier (almost like a template from which databases are created).
As far as SQL Server / MSDE go, this would be overkill for a simple checkboox application anyway. This is more for hard-pounding applications that need transactional services (not that a register wouldn't necessarily benefit from that), replication, user authentication and security, etc.). Besides, it's a big install and can be the cause of many headaches - especially for computer neophites.
If I want to sell this checkbook application - can I guarantee user's will have MDAC installed, and consequently, the Jet database?
If its small and redistributable, I don't mind bundling it - but I'm not sure Mr. John Doe is going to have ADO.NET installed (consequently MDAC and consequently JET) Is an MDAC installation the byproduct of a common application like IE or Office or something.
Also - you've described the database, but I'm a neophyte when it comes to connecting to .NET dbases. I am extremely familiar with JDBC. Is there a similar C# API?
From your description, I don't even think I have to "start" the Jet Database, I just need to find the set of classes that transparently access JET to read and write mdb files.
Is that conceptually correct?
I'll google around. Someone's bound to have an example. At least now I have an idea what I am looking for.
MDAC is the Microsoft Data Access Components, which include ADO, OLE DB, and ODBC. OLE DB providers are the "database drivers" which ADO.NET uses. Microsoft Jet is indeed a separate download, but is pretty small. See the Downloads section of the page linked above (which redirects, actually).
Without MDAC 2.6 or higher installed (MDAC 2.8 is the latest), you cannot use ADO.NET. The Microsoft Jet database engine installs the components necessary to use .mdb files. I'm not sure which one actually installs the Microsoft Jet OLE DB provider, but I'm betting it's the latter one.
MDAC will most likely be on the system. Less likely is that Jet will also be installed. Unfortunately, the .NET Framework setup includes neither technology ( ?). These aren't hard to package, though. The site I linked even discuss deployment.
You don't need a "real" RDBMS for a simple register. Trust me - as someone that has built many installations and consulted both small and large companies on installations, MSDE is not something to be trivialized. Installing it the first time and attaching databases is difficult enough because you have to worry about SQL Server instances and which MSI to use. Maintaining that database through successive installations is a complete nightmare! For the app I designed at my company, we've had to write several utility programs just to update the MSDE installations and then upgrade database changes for both MSDE and SQL Server.
Besides, this runs as a service and it can be hefty. It's too much burden on users' systems for something so simple. MSDE is better suided for data mining and analysis, web sites, and other concurrent-access applications.
lutherbaker wrote: By the way, how does one post hrefs to this forum? try this
As with all web pages, unless you use a relative path or root-relative (absolute) path (which cannot include the hostname), you must include http:// before the hostname. Examples:
As I mentioned in the original post, "I could resort to file based storage" ... If I could cap the total amout of data - or develop a scheme to incrementally load/search data that exceeded some memory limit. I'm just worried that such a solution will not scale well.
Unless I'm reading the entire file into memory, I think this might be a bit slow and I would probably have to implement a searchable object hierarchy. While not the end of the world, thats just not where I want to focus my time right now. SELECT statements are just fine.
I've looked at SQLlite (open source file/embedded dbase) and one day, I may implement a small, file dbase - but for now, runtime XML access/storage might not be feasible.
I will try to encapsulate the data access anyway. It may make sense to use an XML solution for testing and prototype demonstrations.
Do you mean SMS, as in short messaging service (often called "texting" for mobile phones)? You'll need an SMS gateway. Google for "SMS" and you'll find some free and commercial gateways. Sending messages to it depends a little on the implementation (depending on what you need to do), otherwise it is a standard system and documentation would be included with the product (assuming you get even a half-way decent one).
Yes, "MMM" would sound more reasonable. "MMS" is a way of sending images and such stuff from mobile phone to mobile phone. IIRC it is rather expensive (compared with the transmission of voice). Probably 1 cent per byte
Uwe Keim wrote: "MMS" is a way of sending images and such stuff from mobile phone to mobile phone.
Ah, so perhaps Mobile-to-Mobile Service. Seems reasonable. If that's the case, though, the CompactFramework most likely wouldn't support this because it would've been too new. Of course, if it uses sockets, you could always encapsulate your own protocol.
MMS is for multimedia message service.
GSM operators have MMS Servers and these mms servers have interfaces to speak with the outside. Since messages are in KBytes it can not be handled with SMS. Instead it can be handled with HTTP or SMTP interfaces. There might be some special operator interfaces as well. So it depends on the interface of the MMS server. If it is SMTP , you have to handle it using SMTP codes.
Just post a message at the bottom of the article. Messages are forwarded to the article's author(s).
For read-made RTF controls, I'm sure there is existing ones, but this actually isn't hard to do yourself. The RichTextBox already has methods for most of the features you need (like Cut, Copy, and Paste), and things like font families, colors, and styles are hard to do either.
To find existing ones, just search or browse this site, or try googling the rest of the 'net (which includes CodeProject articles in the search, of course).
Heath, thanks, i guess you didn't understand my post.
Upon googling the net i came across an edit control that seems to have some very nice properties. It was written by someone named Filomela and posted Sept 14 2003. It seems to be based on an MFC control (?) called RichEdit.
I would contemplate writing such control myself, since all the elements are there, but it would take me some non trivial amount of time (2 weeks??) to understand stuff like bullets and indents, find the correct images for the buttons, and so on. And after i was all done my code might even have bugs in it.
Furthermore, having already noticed that there are lots of variants of the MFC RichEdit control, which are quite similar to what i'm looking for, i thought this might actually be a common problem. so i thought perhaps the dotnet community might have also have produced either some native versions or a managed wrapper for RichEdit.
But on googling with c# and managed, i didn't turn up anything besides the MFC type stuff. So i thought i'd post the question, and title it "RichEdit wrapper?", to see whether anyone has come across a dotnet version of something like Filomena's article, or if not, would anyone like to recommend their favorite component library with a good lightweight rtf editor?
Thanks in advance!
Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain.
Then perhaps I'd deserve ya, and be even worthy of ya..
if I only had a brain!
TuringTest1 wrote in original post: I'd email Filomela but i can't find any other posts from Filomela except his rather nice article!
It was this statement that prompted me to recommend that you post a message at the bottom of the article. I understood your query just fine.
What I was saying is that the RichTextBox already supports the functionality he's using. He's exploiting such functionality in MFC (using C/C++) just like you can exploit the functionality of the RichTextBox in .NET.
Upon searching - and to my amazement - there really isn't much on canned RTF control solutions complete with toolbars. I can send you some source I have that I wrote for our app. It doesn't have everything you're looking for, but most of it and there should be enough there for you to figure out how to add the rest.
I'll send you the required source and you can look it over. It should compile fine, so just instantiate it and add it to a form. I'll send it to the email address I saw when I got notification that you replied. If you know that won't work, please send me a private email to this message (click the Email link at the bottom of this message).
I don't usually "talk out of my hat". It's from experience and a great memory. Sometimes people that annoy me (those constant reposts or those that don't get the point after 100 messages) I give blind advice to that usually works (but not always), but I hold true to "give a man a fish and you'll feed him for a day; teach a man to fish and you feed him for life". Know what I mean?
Anyway, hope you like it. As I said, the RichTextBox already has all the functionality you need (well, maybe not some wild ideas you might see in Word or from third-party solutions from scratch). It's just a matter of exposing that functionality through a UI.