'SQL Everywhere Edition' - What. How. Why. | Going Deep

Anil Nori

SQL Server Everywhere is a relational store and does not have the file system integration like WinFS did. Yes, it does enable some of the WinFS scenarios. BTW, you can store data from multiple applications in the same .sdf file if they are created by the same user. That is, you can run multiple applications accessing the same .sdf file. The difference is the database (dlls) are embedded in the apps.

Yes, we are exploring XML support. Do you want to just store XML docs or do you also want to query (e.g. using XPath, XQuery)?

Anil Nori

As I replied to some other mail, it is possible for multiple apps to share the same database (.sdf file). SO, there can be n:1 relationship between the apps and the database. The key is it is a single user database (but can be accessed by multiple apps).

Yes two different two databases can be synchronized. Currently, SQL Server Everywhere supports a Hub and Spoke sync model. That is, several Everywhere databases can sync to a server DB (e.g. SQL Server). SO, it is possible for two .sdf s to sync via SQL Server.

In future, we do plan to support Peer-to-Peer sync, where two Everywhere DBs can synchronize with each other.

anil

AlphaKahuna
Customers, THE valuable asset.

Very informative video, great job guys. My friend was telling me recently that he was getting compiler errors when he was calling the Dispose() method of the SqlCeDataReader object. Is this still an issue?

figuerres
???

interesting....

still watching but yes....

very handy.

Dumbledore

This is very cool !!

Several scenarios that I thought were possible through WinFS can be done using this edition. Well, I cannot use data of other applications but persistence and query processor by themselves give lot of power to an application and cuts down lot of custom code. Above all it is free.

Do you have any plans to support XML data type?

TimP

This has been around for a while. Apache Derby (formerly IBM Cloudscape) is DB2 compatible, open source, and written entirely in Java. It can be embedded in an application or run as a server. If I recall the footprint was only like 2MB.

Ravneet

Hi Anil,
This looks like a nice initiative for application scenarios which you mentioned (like flying in a plane and needing the app to run).

My question from that view was, how would SQL Everywhere support distributed apps (with a centralized database?). Correct me if I am wrong, is SQL Everywhere targeted only for 1-to-1 scenarios between an app and an database? What if both you and me are on a plane, and running the same app and making local changes to our copies of database (either to disk or in-memory). Would there be an options to 'synch' our copies later on?

-Ravneet

Anil Nori

Yes, there have been other small footprint SQL databases. SQL Server Everywhere is different from Derby (Cloudscape) in couple of ways:
   - SQL Server Everywhere is componentized -- the storage engine, the query processor, API providers, and the sync components are separate DLLs. So, it is possible for an application to choose just the storage engine without taking the other components. This provides extensibility -- in fact, you could right your own query processor on top of the storage engine

   - SQL Server Everywhere runs on the devices as well as on the win32 platforms. I am not sure if Cloudscape runs on devices

   - SQL Server Everywhere provides flexible sync components. Sync is an important part of the Everywhere scenarios

   - SQL Server Everywhere applications can easily scale up to server apps (to SQL Server)

RichardRudek
So what do you expect for nothin'... :P

Anil, during the interview, you basically dismissed (but justified) the loss of stored procedures. I then started musing over this. I suppose I should preface what I’m about to say by stating up front that I’ve only recently started to work with Relational databases (about 15 months, ago), so if I’m off-base, please be kind.

Anyway, I basically asked myself, “What problems do stored procedures solve ?” and “Is there a way of leveraging these solutions, so that business logic follows, or is synchronised along with the data ?”. Compounding this is the issue of Synchronisation, itself.

Synchronisation, first. A few days ago, there was a presentation at the Sydney .NET users group by Geoff Orr, where he discussed the use of Partitioned Tables, a new (?) feature of SQL 2005 Enterprise, and that seems like a perfect fit for disconnected data sources. In this scenario, each disconnected-user maintains a Partition within each of the (Partitioned) Tables on a Server, and thus user synchronisations are “sandboxed”. Any thoughts on this ?

Now moving to the business logic. Is the reason why your not supporting stored procedures centred around the SQL engine’s size, and if so, would there be any benefit to re-examining how Stored procedures are implemented ?. Eg The stored procedures actually being (re)compiled into .NET Intermediate Language, extending IL, if necessary ?

I suppose I should actually read up on how and when SQL compiles stored procedures, but with experts around... Smiley

. What I’m picturing is that TSQL is initially compiled into IL, and the IL form of the stored procedures are synchronised. If appropriate/necessary, the IL form is then further processed (JIT-compiled) by the respective data storage engine.

Obviously, there are going to be issues with what or how much of the business logic needs to stay with the data (appropriate synchronisation). The point being that at the enterprise-level, we can continue to move business logic into the data-tier (following best practices, yes ?). I’m imagining some form of (high-tech) code analysis, or a rudimentary (programmer-controlled) form of procedure tagging (attributed code).

I wish I had more time to look into WinFS and LINQ. I mean, does LINQ surface stored procedures as methods of a (database) object ?

EDIT: added "to be" to the 2nd last paragraph, near the start.