Zeoslib Portal

Which props really require long descriptions? Most of them are pretty obvious and those which require explanations usually are directly derived from drivers so driver's docs will be better.

Dozens of files each containing one or two lines? I don't think it's a good idea

@frost: I would be happy about a workflow like that. But I don't know about a tool for that kind of source code documentation. These are no properties of classes or anything like that. Do you have any suggestion for doing the kind of documentation process you suggest? I don't think any existing too...

Reasonable wish! But you'll have to define a set of available options anyway (to restrict users from doing something bad) so you'll just need proper descriptions for these options.

Unfortunately (or fortunately )) ) I've no experience in multi-language DB apps but I'm pretty sure than in modern world the real need in codepages is very very rare. So yes, I guess you're right

If you mean docs, then yes you're right
I guess that instead of having two parallel storages of parameters info (sources and wiki) we should better keep everything in sources and just auto-generate wiki page from them.

I could seem rather radical but I'd say codepages are for legacy stuff only, modern stuff should use utf8 everywhere and forget about codepages at all

So there's no list for it at the moment - that's what I thought. Weird conclusion - there IS a list at the moment! Above-mentioned files contain pretty much generic parameters. Any other ones are driver-specific and are defined in ZPlain*Constants units. This might seem inconsistent but this is the...

The difference between auto-managed types and GC is that with the former you always can tell when resources are freed and in the latter you can't. Auto-managed types could make code significantly shorter and cleaner.

I also use short-living query objects for little tasks. I get it with DataModule.GetTempQuery, do what I need and forget about it. As the returned query is wrapped with interface, it is destroyed automatically

I'm not familiar with Oracle but shouldn't Schema be rather a prop of a dataset than of a connection? Connection could access several schemas or am I missing something?

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

Looks good so far. Jan could you change the color of notifications badge and unread icon? It is too bright and bloody now

This shouldn't be so... what happens if you remove lcl dependency?

DavideAmelio wrote:The problem is the opposite: TZconn := TZQuery.Connection ( Abstract )

Why not change type of parameters in your functions to TZAbstractConn? This would be more correct from the point of class hierarchy