Slashdot Mirror
Server CE Database Development with .NET
This book comprises 10 Chapters in just under 450 pages, including the indexes and usual book stuff. Since CE supports ASNI Sql, there are a few chapters that discuss using SQL to manipulate databases, which are probably not necessary for most database programmers. Chapters 4-8 are dedicated to DDL (data definition language), DML (data manipulation language), and taking advantage of metadata. It's a good discussion of these subjects, and I guess an author must include them to be thorough, but if you aren't that familiar with SQL, you probably have some learning to do before diving into data-driven PDA apps.
Enough about the background, though. The book really excels in two areas, one of which I think is probably useful to any developer, even if you don't use the Compact Framework or Microsoft Products. That area is security.
Far too many developers blow off security concerns, or claim to care but do little or nothing about actually increasing security. Let's face it: no matter how secure your OS is, no matter how killer your firewall is, today there are a lot of people trying to break your app and they aren't always outside of your company. Tiffany points to a GIGA Information Group article criticizing the industry for ignoring security on mobile devices.
A lot of what he says is focused on security issues that are 'common sense,' and yet ones that people ignore all the time. It's kind of a shame that a writer needs to explain the benefits of using 'Strong Passwords,' but let's face it, no matter how well you write your app, it won't be secure if you leave the front door open.
In no way am I saying that the author's discussion of security is limited to such elementary topics, but he does a great job of bringing many issues into focus and suggesting ways to deal with them.
The other area that this book really excels in is getting you through replication. This is not a fun topic if you don't know what you are doing and there isn't a lot of literature out there to help you get through PUSH/PULL subscriptions and the like. Pragmatically speaking, of the topics this book covers, Tiffany's coverage of replication is probably going to benefit people the most, because if you can't sync your PDA with your server, you are effectively out of gas. If you aren't a Sql CE user you won't appreciate the value of this chapter, but love MS or hate them, the newsgroups and forums are filled with folks with the same sorts of problems that the author works diligently to get you through.
It's hard to know what will and won't work yet on the Compact Framework and CE. It's quite helpful to have a list of common functions that are supported listed in depth -- another thing I liked about this book.
What else? Well, the text was well written, very similar to his last book on Pocket Access (Pocket PC Database Development with eMbedded Visual Basic) and easy to read. If you are a total newbie to CE, you can use this book and hit the ground running. Everything that you need to write professional apps is included, and I can't find anything that Tiffany omitted.
I really appreciate the fact that the author wrote an entire book on such a niche subject. Many areas, particularly the Compact Framework, don't have a lot of literature on them and if you are writing SQL Server CE, you are on your own...until now.
If you develop in CE, or plan to, this book is a Must Have.
You can purchase SQL Server CE Database Development with the .NET Compact Framework from bn.com. Slashdot welcomes readers' book reviews -- to submit a review for consideration, read the book review guidelines, then visit the submission page.
no, really, i can't. bashing things out of ignorance is fun and easy.
Do we really need more technologies in their infancy? Is it not one of the biggest problem in this industry that we keep inventing new ways of doing the same stuff, throwing out entire generations of products and developers each time?
We need ways to make existing good code last longer, not new frameworks to waste time on.
But... sigh... I don't expect that kind of attitude from Microsoft. One more reason to avoid such platforms like the pest.
Ceci n'est pas une signature
How's stupid enough to run their database server on Windows CE anyway?
Don't think this is a huge focus for Microsoft, they're practising their tried and true method of "throw enough shit against the wall and some of it will stick" marketting. Assuming this product gets a decent foothold then you'll see them really push it.
Trolling is a art,
After all, unless you are simply playing games on the PDA, it probably needs to interact with a database somewhere and I can assure you, just about every common task that you may encounter is discussed in depth. The show you how to bind controls to data, retrieve it from a Web Service, retrieve it from a SQL Server on a local network, use SQL CE to take advantage of replication and using XML as a Data Access technology.
So, if I'm reading this right, the way this is supposed to work is:
1) You bind your GUI controls to a SQL server database using the SQL CE library installed on your PDA.
2) When a GUI control needs to update the data, or refresh it's view of the data, it performs a query using SQL CE.
3) SQL CE then transforms that request into an XML document, sends it over a (presumably) wireless network connection, to SQL Server.
4) SQL Server then processes the request, generates an XML response, and then the whole thing runs in reverse until the response gets back to the control, which can then update itself with the new information.
Is this really the way this thing is supposed to work? Please somebody tell me that I'm reading this wrong.
SQL statements are great when you're trying to optimize for query efficency, but they're awful when you're trying to optimize for network latency/bandwidth. This is because SQL is based on the idea that you perform operations over a persistant connection, because establishing that connection and performing the query is usually the bottleneck.
But any wireless developer will tell you that latency/bandwidth is the major bottleneck in a mobile application. When you're sending data over CDMA/GSM networks, the best data rate you can hope for is 192kbps, and forget about low latency. This means you have to package your requests in a big bundle and do them all at once. Which means you need something a little more coarse-grained than SQL.
I suppose if you assume that your application will always have 802.11 access, this could be a good model. But otherwise you're going to be waiting 5-10 seconds every time you click a button, change a setting, or scroll down through a list. Which means nobody is going to actually use your application because it's a grand waste of time.
to store the english alphabet. :)
Performance was good unless you wanted the results sorted
So far many of the comments seem to be along the lines of, "SQL Server for a PDA?! WHY?!" Well, why not? Think about where PDA's could be headed. Why not have the PDA be the server for your Personal Area Network?
PDA's these days are getting more and more powerful. They're already as powerful as what was on the desktop less than a decade ago, and they're catching up fast. It's not unreal that in 5 years we'll have PDA's capable of running Half Life 2 and Doom 3. I mean, today's PDA's can already run Quake 1 and 2.
So back to SQL Server. Why is it bad that they are developing a version of SQL Server running for this kind of platform? It seems the perfect starting point for some really powerful mobile apps.
This is pure and simple FUD.
Not ONE of these technologies listed is obsolete or not used any more.
Bash MS all you want, when you can back it up.
When you bash MS and don't back it up, it kinda null and voids all of your other arguments.
No Comment.
That's why I look forward to the completion of a few last (for this) features in Firebird (the database server) -- they have an 'embedded' version that sits in a .dll and acts exactly like the server version as far as the calling program is concerned. It's the same engine code, so the same SQL is supported, the same features available. It can still load UDF libraries (the same ones it loaded as a server) but won't accept connections from other programs. If you want several programs to access the same file at the same time, you'll have to do that yourself. It's already great for building single-user programs to be distributed to clients who wouldn't want a "full-blown" database server running (really, it is, but at least it's not listening to any ports.)
Firebird/Interbase has always been rather small -- 10 meg install, very little memory usage. The main problem porting it to PDA's and other embedded devices was its loopback / inter-process-communication systems. Its shared-memory method wasn't completed (though from what I hear, they have it working in development versions, and the new method speeds up the server quite a bit as well) and it relied on 127.0.0.1 loopback. Windows CE didn't allow for that (no ethernet interfaces at all by default, not even lo) and thus the server couldn't talk to itself. (It tends to use multiple processes.)
Regardless, Firebird will most likely be available for embedded devices soon, run quickly and quietly, and won't be a stripped-down version at all. Code written for large multi-user environments would still work, but you might have to wait a bit longer for your huge reports.
(And yes, I feel fine writing this without being too concerned about vaporware -- it's already proven technology, it's actively worked on, and the Microsoft thing isn't any closer.)
We agree that progress is good. No-one regrets the passing of days when we hand-coded interface languages because XML had not been invented.
Part of my point.
But you make the mistake of many people, namely to assume that change is equal to progress.
Change in itself can be tied to progress. Changes can happen based on progress, especially when it comes to new technologies (in their infancy) like the internet. The invention of HTML (the most simplistic example) lead to the first sharing of information on the WEB. That first Web page *changed* the way we share information forever. Is information sharing new? Of course not. Is the way we share it new? Yes it is. That is advancement, it's progress. Now html is already being called *old*. So my point is change and progress go hand in hand. In many cases, that can be like the chicken or the egg story, but one thing is for sure, there is constan change and progress happening.
Change is only part of the cycle. The other part of the cycle is the refinement of techniques and maturation of knowledge that lets you exploit change to the fullest.
It all depends what type of change we're talking about. Some changes happen as a direct result of us *creating*, advancing, inventing.
Imagine if every three years we had to discard languages like HTML and XML and start with new, incompatible concepts. The market would never get into a state where mature concepts could be built: it takes 2-3 years at the least before businesses understand and trust technical platforms well enough to use them effectively.
I agree. But we are not doing that. HTML is still around, UNIX is still around, so is Windows 3.1. So after all we're not changing things that much. You are not being *forced* to adopt all these new technologies, but you do have the option, and in time you'll migrate to them. That's why there's always a strong emphasis in *backward compatibility*. I know this is a lame example, but I have an *old school geek* friend that develops Access Applications. If you look at his code the syntax is still completely in Access VBA 2.0. (now we're at Access 11 VBA 7??) I think he's affraid of change. When I mention OLE, or ADO to him he get scared to death. he won't touch them. He says they are *new* unproven technologies, and that ODBC and DAO are good enough. I do agree and strongly disagree at the same time
Yet this is the basic premise of Microsoft's marketing strategy: saturate the market with new development platforms, capture the pioneer developers and keep the customer base forever unstable and tottering in Microsoft's direction.
I couldn't comment on MSs marketing strategy, since I do not know it, but all I can say is that for me as a developer what MSs marketing says means nothing. I think marketing new things to geeks is the most difficult thing on the planet. You have to go to great lengths to convince me to be a convert, early adopter or what have you. I think the customer has the ultimate power, especially at times like these. MS cannot keep a customer *tied up* to their platform anymore. They are (actually) trying hard to keep them by comming out with decent products, rather than relying solely in the marketing and monopoly positions.
Agreed that many vendors try this: "if you're going to base your business critical application on an untested platform, at least use ours". But Microsoft's scale and marketing push make it a much more serious issue.
I don't know what to say here. They do have the money, so a bigger then average marketing campaign for a new product from MS is unavoidable.
Change is not progress. Change mixed with periods of maturation can be progress.
I hear you completely. However I think Change and Progress are two different things, tied together, and happen in no particular order.
The phaomnneil pweor of the hmuan mnid. Fcuknig amzanig eh!