I’ve built quite a few database-driven web applications using Adesso, so I am quite familiar with its offline capability, its integrated design environment (IDE), and its synchronization engine. After all, I started using Adesso all the way back in 2003. Sure, it’s a bit dated now (we are working on this…more details to follow on a forthcoming blog article). But there is still—even in 2013—absolutely no sync engine out there that can match Adesso Sync. If you think otherwise, prove it to me. I welcome the challenge.
My Experience with Straight-Up SQL Server
About 3 years ago, I was convinced by others that for our chain of custody software application concept, I should use native Microsoft SQL Server instead of Adesso. Reasons cited (by other expert developers) included:
“…the web apps will have a direct path to SQL Server, with less overhead to process than if they use Adesso”. (Translation: web pages will load faster)
“…SQL Server can handle massive quantities of simultaneous hits”.
“…SQL Server is well known within the corporate world, so you won’t have much to explain when someone asks you about the underlying database engine”.
So, like an idiot, I bought into those arguments and decided to build our chain of custody tool using native SQL Server instead of our own Adesso Server database. Man, what a mistake that was. We are three years into this (after expending a huge pile of money), and I think the only way I would ever use native SQL Server again instead of Adesso (or Wakanda) for the database engine is if someone put a gun to my head. Otherwise, no way I would ever ever do that again.
Why? Let me explain.
Yes, SQL Server is robust and can handle anything you throw at it. But so can Adesso, because Adesso also uses SQL Server as the database repository, is 64-bit, and can be load-balanced and handle just as many web calls as SQL Server. But at least Adesso contains seriously easy-to-use administrative tools and built-in APIs for any data exchange imaginable. It also happens to be the best commercial sync engine in the world, bar none.
Building Apps with SQL Server as the db is a Pain in the Ass
SQL Server does not come with easy-to-use tools, built-in APIs, or rich sync. It comes with SQL Server Management Studio, which in and of itself is OK, but to use it, you will need to use a VPN connection if you want to access your server database remotely, which adds more layers of latency with which to deal. And if you are using SQL Server on Microsoft’s Azure platform, that’s even more of a challenge.
As for APIs to exchange data between SQL Server and other databases or applications, you will have to build those, too. And what if you want to have an application that can handle offline data and sync back to the database, bi-directionally (like, for example, a native iPhone app)? You are going to have to figure out how to build your own synchronization scripts and logic to handle the sync properly, which is prone to a humongous list of human error bugs when coding it in.
In my opinion, building something in SQL Server is analogous to building a car from a kit with 10,000 parts and a crappy manual. Sure, you can build a Porsche with it, but the sheer amount of effort to get it done is gargantuan when compared to what you can do with something like Adesso in a fraction of the time. Yes, a FRACTION of the time. Like maybe in 20% of the time it takes to do with native SQL Server.
It takes a huge effort to build something with SQL Server, and frankly, it’s just not worth it when there are other tools that are easier to use and manage the database.
I’d like to point out that I’m not saying this to sell copies of Adesso. I am saying these things because after 3 years of building a complex product using SQL Server, I now really appreciate what we have in Adesso, and I kick myself daily thinking about the amount of money and time we would have saved if I didn’t listen to anyone and just went with my gut and built it with our own damn tools.
So What’s So Great About Adesso?
Take a look at the screenshots below.
These are screenshots of Adesso’s SyncAdmin web portal, where, with a few clicks, you can set up user and group permissions and sync rules down to an individual column in a table. So, for example, you could set up a user group to be allowed to view and write data to a particular table column, and another group to only view data entered in that column, and a third group could be set up to not even be allowed to view data in that column at all (fields would be greyed out on their screen).
As for sync itself, you can set up full bi-directional sync (with conflict resolution settings) between the offline client machines and the server, with the ability to add filters in either or both directions, and you can set these up to be different for different users or user groups. This allows you to easily build multi-tenet applications that have to handle data records differently between users and groups. And all of this is in real-time, meaning that if you change any of the permissions or sync settings, the next time your users sync up, those changes take effect immediately and automatically.
Fine-Grained Offline Permissions Is Not Even Possible with SQL Server
Try that shit with native SQL Server. It’s not even possible. You have to build your sync rules yourself. With Adesso, all of that is already handled, tested, and proven out. And if you decide to edit your application’s schema, maybe add another column to a table, or create a new form that displays when a user enters a particular value somewhere? Just make the changes in the Adesso Designer and click on the sync button…presto…all of the schema changes are also pushed down to the individual client devices the next time they sync.
I will never ever ever use SQL Server again to build a product. I learned my lesson the hard way, and at much higher and unnecessary cost and time. Never again. You can be sure that all of my current and future projects (including BernieSez and all enterprise-level applications we build for AEP and Duke Energy) use Adesso as the underlying database engine and technology.