In-memory "driver" for Zeos?

[aehimself]

I think this question was asked already, but I could not find it on the forum. Is there a way to create a dataset in a ZQuery without having a database connection opened? I need to "simulate" results in a data-aware component and it would be awesome if Zeos could handle this for me.

As far as I recall there was a request for a webapi driver too (build a dataset from JSON / XML / something)... which could use the in-memory dataset "driver" to create it's dataset, maybe?
Unfortunately my knowledge is waaaaaaaaay too insufficient to implement this by myself, so is something like this already possible / in the queue?

Thanks!

[aehimself]

I'm experimenting with TClientDataSet.CreateDataSet, but I really don't like the dependency on midas.dll. So far my options are creating a temporary SQLite database or forgetting data aware components, creating a two dimensional variant array and use a grid-like component to manually display the data.

- I don't like the first option because it depends on sqlite3.dll and because it seems overkill, and
- I don't like the second option because since I'm using a custom DBGrid descendant it would take waaaaay too much work to make the grid-like component to look and act like it

[Fr0sT]

Usually this is called "mem table" and it actually would be pretty nice to have this in Zeos.

[marsupilami]

Regarding TClientDataset: As far as I remember, it is enough to add the MidasLib unit to the uses clause of your project to get rid of the dependency on the dll.

Regarding in memory on Zeos: Well - Zeos can do that to some degree. The metadata functions do that in some drivers. Dblib would be one such example. But there is no supporting infrastructure for doing that. I assume, one could come up with a solution that is similar to the ClientDataset and creates a valid ResultSet for a Dataset that already has fields defined. I am not sure though, if our TZQuery component is prepared to work on a IZResultSet that has no connection attached.

Also there was a user who wanted a driver for an in memory database: viewtopic.php?f=15&t=19163

[aehimself]

I started to use TClientDataSet, but my DBGrid descendant component depends on Zeos so heavily (sorting, ordering by title clicks, extra information on it's own status bar, etc) I decided I'm not going to care about it.
For the time being I am creating a SQLite database and using a TZQuery for my needs. I'm not really happy with this solution, though

[marsupilami]

hmmm - how should an in memory driver work? How should it get its data about the dataset structure? Should that be derived from TZQuery.FieldDefs? Or should there be some kind of specification in the TZQuery.properties like this:

Code: Select all

ZQuery.Properties.Add('structure=field1 integer, field2 varchar(40), field3 memo')

Would we expect the data to somehow survive a cycle of TZQuery.Close / TZQuery.Open?

Would we want the possibility to store data and reload it?

[aehimself]

How should it get its data about the dataset structure? Should that be derived from TZQuery.FieldDefs?

To keep the similarities with TClientDataSet I guess FieldDefs would be the ideal way to go: https://stackoverflow.com/a/275132

Would we expect the data to somehow survive a cycle of TZQuery.Close / TZQuery.Open?

Data? No. Structure? Now that's interesting: if it could be kept that would be the best but since it's in-memory, discarding it would make sense too.

Would we want the possibility to store data and reload it?

Store, like .SaveToStream / .LoadFromStream? It's quite easy to do (just save the structure / data in a custom format), but compatibility will always require end-users to make their own implementations anyway (store to XML, JSON, they don't need structure; only data, etc).