Let me clarify then. 100% of our customer want web based. With .NET and SQL server we can throw in our data adapter and be off to the races. We don't have to worry about future scalability. With Sqlite, you dont' receive a trusty data provider. Good ones exist, but all of this extra work boils down to time cost. As well, what if you want to move the database to another machien to distribute workload.
Well, our bug tracking system Swatter we did use Sqlite but we had to write the thead syncronization layer. In fact, it is a .nET application that runs across a web service or a sockets layer, to a sqlite database eventually. Our sql server version does not require any special coding like sqlite. So after 250k lines of code in our bug tracking system, we have a picture painted. The sqlite version is what we use, not the sql server but we deal with the corporate requirments as well like this fellow is up against. Does SQLite have a distributed API now. This means a client that talks efficient binary across a network to a server that eventually syncronizes into database work? Did I miss something. I thought this thing was only a binary that you have to do everything else on top of. Allan ----- Original message ----- From: "cirisme" <[EMAIL PROTECTED]> Date: 1/31/2005 12:24:23 PM Subject: Re: RE(1): [sqlite] SQLite Advocacy > >>Their are still sa couple extra features missing from this db that > would make it a true contender for business software.<< > > Too general of a comment. If the business software requires a > distributed database, SQLite fits the bill. If the business software > requires a central database, SQL Server is probably more suited. > > It just depends on the exact nature of the requirements. >
