Just so you know this is what Heath said to the last
guy that asked about getting certified in .Net.
Heath Stewart said
"Personally, I am not certified because I really don't want to be. I know a large number of people with certifications that know crap. They studied for the tests, memorized a few things, took the tests (sometimes a couple times) and got their certs. They're still idiots."
And this question prompted me to write in my personal message board on my profile page. I mean, he's going to get certified and doesn't even know how to find cert material? Every cert candidate should know about http://www.microsoft.com/traincert[^]!
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.
Last Visit: 31-Dec-99 18:00 Last Update: 25-Sep-23 7:55