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.
MSSQL CE, that's what.
no, really, i can't. bashing things out of ignorance is fun and easy.
Geez -- a crippled db platform if there ever was one. Calling it "SQL Server" is really a major misnomer -- the two are not even remotely similar in even basic features. Obviously, this would be expected to some extent -- but the name tends to mislead. I had the misfortune of working for an employer who wanted the same application working on both SQL Server and a handheld version on CE. They expected significant code to be shared between the two, and ultimately got a nasty surprise when this proved infeasable, given the alotted dev time frame.
Roving Web-Teleoperated Robot
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
While I haven't been interested in shelling out the $$$ for Microsoft's server product (getting data back to the desktop database is important to me) I can say that I haven't found any database solution that operates as quickly as MySql on a PDA.
My Zaurus is running as a full fledged server and its rock solid. Even the desktop ODBC connector is able to pull data into my windows apps at a surprisingly fast rate of speed. In a word it's simply awesome. I just wish my PHP skills were better.
For the mortals Microsoft offers an Access compatible format (pocketAccess) that's horribly limited and slow. There are some great PocketPC database apps that are crippled by this horrific database solution that could be killer apps with a free backend.
www.lonseidman.com
Well if all the information is in RAM then think of how fast transaction time will be with no disk reads, then realize the power of SQL server on a PDA.
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,
It will be secure if you leave the front door open, but have a tiger pit cleverly disguised just inside the doorway.
Thieves tend to go to the path of least resistance, and unless they see one of their criminal compatriots plummeting into the tiger pit, or hear the horrible screams that follow, this is their most likely point of attack.
Or was that just a metaphor?
The very high quality embeddable SQLite database has several ports to .NET -- see the web site.
Comment removed based on user account deletion
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.
Compact, as in "a compact with the devil".
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
He's a witch! Burn him!
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
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.
This is not like a simple recompile of the beast that is MS SQL server. It is a new product designed for PDAs. However, it still seems rather silly.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Build your application as a web app using ASP.NET/PHP or whatever. Use whatever SQL backend you want and have it run on a REAL server that is meant to do that work.
On the PDA, throw a 802.11b card in when at the office and some sort of cellular card for when you are out and about. The only software you need on the PDA is a good web browser. Bandwidth is much less of a issue because all you are transfering back and forth is simple HTML.
It took 10 chapters and 450 pages! Damn I can do it in 4 words: Do NOT do that. Yup, MSSQL a ten's of megabytes application, let's dumb it down and use it manage a few hundred megabytes of compact flash on a handheld or embedded device, yup that's a plan. I guess it's like the man said: when all you have is a hammer, everything looks like a nail. I guess Microsoft needs a bigger data management toolbox.
...why separate the database engine from the development tool on a palmtop, where efficiency is paramount? Do they expect people to use a palmtop as a db server or something?
Something like Foxpro or Access, with integrated database support, would make a helluva lot more sense. The latest version of Foxpro for the PC has a smaller runtime than what they are cramming on there for SQL CE for chrissakes! It's fuggin silly. What gets IN to those people?
10 years ago, I was putting the entire foxpro for dos development environment on 1 meg HP xxLX palmtops, and it worked really well. Full portability between desktop and palmtop, good performance, and good stability. Why have we taken such a giant step backwards that despite the hardware being 100 times better, we can no longer build decent software to run on it?
Everything MS does anymore should be accompanied by clown music.
I am truly starting to believe that MS is going to be a niche player like Apple in 10 years...an idea I would have laughed at a few years back. I don't LIKE this idea...it means I have to spend a lot of time retraining...but the writing is on the wall.
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!