Michael Van Canneyt wrote / napísal(a):
On Mon, 2 Jun 2014, LacaK wrote:
Daniel Gaspary wrote / napísal(a):
On Mon, Jun 2, 2014 at 3:01 AM, LacaK <la...@zoznam.sk> wrote:
IMO very similar result you can get also with existing
implementation, when
you use:
Yes, this is the way GetDBInfo do, but it's not public, and never
return schema.
Code which I have attached uses only public methods and returns
"metadata dataset" which has also schema_name column
(for SQLConnection which support schemas. I have used public method
SetSchemaInfo not GetDBInfo)
What I did was to copy and modify this method.
I have sent a patch: http://bugs.freepascal.org/view.php?id=26254
Yes I see it, but as I wrote your new method returns collection,
which you must process, which is more or less what you can do with
"metadata dataset"
While this is correct, the collection approach is much easier to use:
With the metadataset, you must know which fields exist and type them
correctly: FieldByName('XYZ').AsString
With collections, the IDE codetools will tell you what properties exist.
That is a order of magnitude more comfortable and less error prone.
I still feel it a bit incompatible with existing interface.
If existing methods are not enough then we can return to already
discussed extension:
TSchemaOption = (soIncludeSchemaName, soSystemObjects, soQuoteNames);
TSchemaOptions = set of TSchemaOption;
and
TSQLConnection.GetTableNames(List: TStrings; SchemaName : String;
Options : TSchemaOptions);
or better "new":
TSQLConnection.GetObjectNames(List: TStrings; SchemaType: TSchemaType;
Options : TSchemaOptions);
Which IMO fits better in existing frame.
-Laco.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
