|
CityDesk DataAccess Library?
Does CityDesk use DAO or ADO? What influenced that decision?
Dave B.
Wednesday, October 22, 2003
DAO, because it was more complete, debugged, and mature at the time we started development.
Joel Spolsky
Wednesday, October 22, 2003
(And also because it handled some Jet operations natively, things like Compact and Repair database)
Joel Spolsky
Wednesday, October 22, 2003
Check out SQLite :-) Less hassle, and maybe sufficient in terms of features than a stand-alone app like CD.
www.sqlite.org
Frederic Faure
Wednesday, October 22, 2003
Joel,
Thanks for the reply(s). I have one more question for you. Did the fact that ADO is not able to do table/recordset level locks have anything to do with your decision? (i.e. Was this type of locking important to CityDesk?)
(Maybe the newest version 2.8? of ADO is able to do so, I haven't looked into it.)
Dave B.
Wednesday, October 22, 2003
Well, I'll add one more. (hehe) Would you use ADO now if you could start over?
Dave B.
Wednesday, October 22, 2003
Even if CityDesk were rewritten using ADO how would you compact and repair a database with ADO? I think DAO has those two (table level locks) advantages (plus some other rarely used features).
Anon
Wednesday, October 22, 2003
Apparenty PHP will start being shipped wuith SQLite embedded in it.
Matthew Lock
Wednesday, October 22, 2003
I think that DAO is a perfect fit for CityDesk for a lot of reasons besides the built-in cpct/repair functionality.
The site "documents" that CityDesk uses have to hold an immense amount of data (images, html files). How can you best manage that data? Personally, I like the relational SQL model the best. What other client side only storage solutions are there that let you query/aggregate data using a language like SQL?
You could use an OLE Structured Storage file, but is there a toolset for working with them provides as much flexibility as DAO?
You could use the hard drive and store all of the objects as seperate files. But this is not as good for the same reason as an OLE file. ADO is wrong too because you really can't issue SQL statements to a client sided cursor. You can Filter and Sort ADO recordsets, and save them into Streams, but without a server you can't really do SQL (right?).
Then, there are things like SQLite. No offense to the person who recommended it, I could be wrong but just looking at it's home page I don't have confidence that it's as good as DAO with an Access Database.
At one time DAO was hyped as much as ADO or XML is today, so it's pretty solid when using it with Access. I think one reason Microsoft wants us not to use it is because it is trying to convert the world into a subscription model for it's own benefit. Maybe for ours too :)
Wayne
Wednesday, October 22, 2003
Sorry, I know my last post seemed off. I did not acknowledge that you can also use ADO with an Access file, BUT if you're going to use Access you HAVE TO Compact/Repair (if you don't you're customers will be asking you to soon).
Wayne
Wednesday, October 22, 2003
Using JRO "Jet and Replication Objects", you can compact/repair and encrypt/decrypt databases. I believe the MS Jet OLEDB v4.0 provider also exposes the IJetCompact Interface which can be used in a similar manner.
Dave B.
Wednesday, October 22, 2003
I've been looking at SQLite (thanks to mention on this forum) and I'm looking at porting it to a portable computing platform.
I was VERY surprised and impressed with the expressive power, performance, and stability of SQLite.
There are a few problems with it:
1) No unicode support
2) No BLOB support; can't easily store even small binary data.
Otherwise, I think it's definitely the way to go for an embedded application database.
Almost Anonymous
Thursday, October 23, 2003
No Unicide support but the way to go for an embedded database.
so you're embedding your database in a portable device, and then limiting the portability to courntries that use the Latin alphabet?
Stephen Jones
Thursday, October 23, 2003
"No Unicide support but the way to go for an embedded database."
Assuming, of course, you don't need unicode or blobs. Obviously, this wouldn't work well for Citydesk. But I can think of a few applications where sqlite would be an improvement over installing MDAC.
"so you're embedding your database in a portable device, and then limiting the portability to courntries that use the Latin alphabet?"
I'm just dealing with one problem at a time! I've not yet got it up and running 100% (more like 25%) on the platform. I'm looking at a few solutions for dealing with unicode. One is to store everything as UTF-8 and replace the string handling functions with UTF-8 aware functions. However, there would be a performance hit doing the UCS16/UTF8 conversion for all data coming in and out of the library.
The long term solution is just to fix sqlite so it uses wide chars and unicode string functions. Sqlite isn't a large library so that might also be doable. I'm investigating this possibility.
Almost Anonymous
Thursday, October 23, 2003
My bad... Sqlite already supports UTF-8 unicode.
Almost Anonymous
Thursday, October 23, 2003
 Recent Topics
Fog Creek Home
| 
