On 19-4-2012 11:14, LacaK wrote:
> Reinier Olislagers wrote / napísal(a):
>> On 18-4-2012 8:27, LacaK wrote:
>>> for stIndexes : CatalogName, SchemaName, TableName, IndexName,
>>> ConstraintName, IsPrimary, IsUnique, IsAscending
>>> (in list are included also PRIMARY KEYs and UNIQUE constraints)
>
Reinier Olislagers wrote / napísal(a):
On 19-4-2012 11:14, LacaK wrote:
Reinier Olislagers wrote / napísal(a):
On 18-4-2012 8:27, LacaK wrote:
for stIndexes : CatalogName, SchemaName, TableName, IndexName,
ConstraintName, IsPrimary, IsUnique, IsAscending
(in list are included
Reinier Olislagers wrote / napísal(a):
On 18-4-2012 8:27, LacaK wrote:
I don't have Delphi with dbExpress here, so can't test.
I did some tests in Delphi XE with DBExpress and MySQL:
for stTables column names are: CatalogName, SchemaName, TableName,
TableType ('TABLE')
So d
On 19-4-2012 13:28, LacaK wrote:
> Reinier Olislagers wrote / napísal(a):
>> On 18-4-2012 8:27, LacaK wrote:
>>
I don't have Delphi with dbExpress here, so can't test.
>>> I did some tests in Delphi XE with DBExpress and MySQL:
>>>
>>> for stTables column names are: Cat
> Thinking about column names I would suggest, change it according to
> SQL-Standard (information_schema views). To be fully compatible.
> (because ATM we are not compatible with SQL-Standard NOR Delphi)
> Advantage will be, that we will be able do for example 'select * from
> INFORMATION_SCHEM
Reinier Olislagers wrote / napísal(a):
Thinking about column names I would suggest, change it according to
SQL-Standard (information_schema views). To be fully compatible.
(because ATM we are not compatible with SQL-Standard NOR Delphi)
Advantage will be, that we will be able do for example 'se
On 19-4-2012 14:13, Ludo Brands wrote:
>> Thinking about column names I would suggest, change it according to
>> SQL-Standard (information_schema views). To be fully compatible.
>> (because ATM we are not compatible with SQL-Standard NOR Delphi)
>> Advantage will be, that we will be able do for
Ludo Brands wrote / napísal(a):
Thinking about column names I would suggest, change it according to
SQL-Standard (information_schema views). To be fully compatible.
(because ATM we are not compatible with SQL-Standard NOR Delphi)
Advantage will be, that we will be able do for example 'select *
>Ludo here I do not understand what do you want to say. may be, that my
english is not so good ;-)
>Can you explain please what is your proposal regarding to stIndexes ?
stIndexes is currently not implemented: keep it that way (or drop it) but
add and implement stTableConstraints, stReferential
On 19-4-2012 15:02, Ludo Brands wrote:
>
>> Ludo here I do not understand what do you want to say. may be, that my
> english is not so good ;-)
>> Can you explain please what is your proposal regarding to stIndexes ?
>
> stIndexes is currently not implemented: keep it that way (or drop it) but
On Thu, 19 Apr 2012, Reinier Olislagers wrote:
On 19-4-2012 15:02, Ludo Brands wrote:
Ludo here I do not understand what do you want to say. may be, that my
english is not so good ;-)
Can you explain please what is your proposal regarding to stIndexes ?
stIndexes is currently not implem
On 19-4-2012 15:37, michael.vancann...@wisa.be wrote:
>
>
> On Thu, 19 Apr 2012, Reinier Olislagers wrote:
>
>> On 19-4-2012 15:02, Ludo Brands wrote:
>>>
Ludo here I do not understand what do you want to say. may be, that my
>>> english is not so good ;-)
Can you explain please what i
On Thu, 19 Apr 2012, Reinier Olislagers wrote:
On 19-4-2012 15:37, michael.vancann...@wisa.be wrote:
On Thu, 19 Apr 2012, Reinier Olislagers wrote:
On 19-4-2012 15:02, Ludo Brands wrote:
Ludo here I do not understand what do you want to say. may be, that my
english is not so good ;-)
Hi Admin, i hope its not forbidden here, otherwise please delete this mail.
Hi all,
we are a 9 person company looking for
a hardware-near software engineer or programmer
or a
software-near electronic designer.
for embedded systems and HTML based user interfaces.
We are developing and producin
> > Has anybody used this functionality in sqldb at all?
>
> No. For a simple reason:
>
> I implemented all this information in fpdatadict;
> I think it belongs more there, and definitely not in the
> basic data API.
>
Some of the metadata are necessary in the basic data API (tables, columns
On Thu, 19 Apr 2012, Ludo Brands wrote:
Has anybody used this functionality in sqldb at all?
No. For a simple reason:
I implemented all this information in fpdatadict;
I think it belongs more there, and definitely not in the
basic data API.
Some of the metadata are necessary in the bas
On 19-4-2012 16:07, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
>
> It's a historic issue:
>
> I think fpdatadict was historically implemented first. It was
> implemented separately because I do not believe this belongs in sqldb.
> For instance, the data dictionary also supports DBF fi
> Now, supposing it must remain in sqldb:
>
> I do not know if the calls for schema information will
> provide all info that datadict needs. If they do not, then I
> must re-implement them in datadict. If they do, then the
> default fpdatadict information retrieval routines
> can use the new s
On Thu, 19 Apr 2012, Reinier Olislagers wrote:
Proposal
1. As I'm interested in getting support for MS SQL Server and Sybase ASE
into lazdatadesktop, I propose I'll go on with trying to make that work
using the current sqldb structure. This will mean that a lot of code
will go into n
> But adding some aliases and add new features such as
> octet_length should
> not be a problem (NUMERIC_SCALE exists in precision).
>
And where exist NUMERIC_PRECISION then? This is used in databases like
Oracle that use numerics. A number(10,4) has precision 10 and scale 4, radix
10.
Ludo
On Thu, 19 Apr 2012, Ludo Brands wrote:
But adding some aliases and add new features such as
octet_length should
not be a problem (NUMERIC_SCALE exists in precision).
And where exist NUMERIC_PRECISION then? This is used in databases like
Oracle that use numerics. A number(10,4) has precis
> As for re-using existing terminology (schema data etc.), this
> is dangerous
> as it creates the expectation that the implementation
> conforms to a certain
> standard, which is what I want to avoid.
>
> (I don't believe I've ever used the word schema in connection
> to a database. I think
On Thu, 19 Apr 2012, Ludo Brands wrote:
As for re-using existing terminology (schema data etc.), this
is dangerous
as it creates the expectation that the implementation
conforms to a certain
standard, which is what I want to avoid.
(I don't believe I've ever used the word schema in connecti
> > There are other databases (mssql, oracle) where it is
> difficult to not
> > use schemas. So even when not using the word 'schema' the concept
> > should be represented somewhere.
>
> Ehm, the datadictionary is the schema ?
>
> Unless I misunderstand the meaning of schema :-)
>
Aha. That
On Thu, 19 Apr 2012, Ludo Brands wrote:
There are other databases (mssql, oracle) where it is
difficult to not
use schemas. So even when not using the word 'schema' the concept
should be represented somewhere.
Ehm, the datadictionary is the schema ?
Unless I misunderstand the meaning of s
> >
> > Schemas "own" more objects than just Tables, Sequences and
> Domains. So
> > I wouldn't have guessed that one.
>
> Correct. fpDatadict is a work in progress.
>
> I use tables, sequences, domains, indexes and foreign keys.
>
Exactly because indexes and foreign keys have also an owner s
On Thu, 19 Apr 2012, Ludo Brands wrote:
Schemas "own" more objects than just Tables, Sequences and
Domains. So
I wouldn't have guessed that one.
Correct. fpDatadict is a work in progress.
I use tables, sequences, domains, indexes and foreign keys.
Exactly because indexes and foreign k
> > Exactly because indexes and foreign keys have also an owner schema
> > (CONSTRAINT_SCHEMA), I overlooked datadictionary.
>
> I am not familiar with these terms, so I totally fail to understand
> the first part of your sentence...
>
> Is there somewhere a reference about 'schema' data ?
>
Reinier Olislagers wrote / napísal(a):
On 19-4-2012 15:02, Ludo Brands wrote:
Ludo here I do not understand what do you want to say. may be, that my
english is not so good ;-)
Can you explain please what is your proposal regarding to stIndexes ?
stIndexes is cur
Reinier Olislagers wrote / napísal(a):
Proposal
1. As I'm interested in getting support for MS SQL Server and Sybase ASE
into lazdatadesktop, I propose I'll go on with trying to make that work
using the current sqldb structure. This will mean that a lot of code
will go into new datadi
On 18-4-2012 8:27, LacaK wrote:
>> I don't have Delphi with dbExpress here, so can't test.
>>
> I did some tests in Delphi XE with DBExpress and MySQL:
>
> for stTables column names are: CatalogName, SchemaName, TableName,
> TableType ('TABLE')
So difference with FPC: the names (catalog_name, s
On Thu, 19 Apr 2012, Reinier Olislagers wrote:
On 18-4-2012 8:27, LacaK wrote:
I don't have Delphi with dbExpress here, so can't test.
I did some tests in Delphi XE with DBExpress and MySQL:
for stTables column names are: CatalogName, SchemaName, TableName,
TableType ('TABLE')
So differen
On 19-4-2012 9:41, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
> On Thu, 19 Apr 2012, Reinier Olislagers wrote:
>> Plans
>> =
>> I'll focus on getting lazdatadesktop/datadict support for MSSQL/Sybase
>> running first; afterwards we can look at the things we can add for other
>> datab
Reinier Olislagers wrote / napísal(a):
On 18-4-2012 8:27, LacaK wrote:
I don't have Delphi with dbExpress here, so can't test.
I did some tests in Delphi XE with DBExpress and MySQL:
for stTables column names are: CatalogName, SchemaName, TableName,
TableType ('TABLE')
So d
34 matches
Mail list logo
