[SQL] Kolomnamen uitlezen

[Maarten Wierda]

Hoi n.i.w.s-s,

Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
database te lezen.

In MySQL is dit mogelijk met de functie SHOW
<http://www.mysql.com/doc/en/SHOW.html>. Nu is het de bedoeling dat ik
een soortgelijke functie vind die ik ook kan gebruiken in andere
SQL-databases:

- PostgreSQL
- MSSQL
- Interbase
- Oracle 8/9

Kan iemand mij hiermee op weg helpen? Alvast bedankt voor de evt.
reacties.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Rene Pijlman]

Maarten Wierda:
>Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
>database te lezen.

SELECT *
FROM INFORMATION_SCHEMA.COLUMNS

Bron: het boek "SQL-99 Complete, Really" van Peter Gulutzan & Trudy Pelzer
(1999).

Misschien ook een nuttige link:
http://www.databasejournal.com/features/mssql/article.phpr/1567611

>In MySQL
>- PostgreSQL
>- MSSQL
>- Interbase
>- Oracle 8/9

Ik denk dat je even per DB in de documentatie moet zoeken naar
INFORMATION_SCHEMA (trefwoord: SQL Catalog).

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Maarten Wierda]

Rene Pijlman wrote:

>>Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
>>database te lezen.
>
> SELECT *
> FROM INFORMATION_SCHEMA.COLUMNS

Op de e1n of andere manier krijg ik de volgende foutmelding terug als ik
dit commando uitvoer op mijn MySQL database (versie 3.23.47-nt):

Table 'INFORMATION_SCHEMA.tables' doesn't exist

Het commando 'SELECT * FROM INFORMATION_SCHEMA.TABLES' geeft ook niet
hetzelfde resultaat als SHOW TABLES. Wederom dezelfde foutmelding...

> Bron: het boek "SQL-99 Complete, Really" van Peter Gulutzan & Trudy Pelzer
> (1999).
>
> Misschien ook een nuttige link:
> http://www.databasejournal.com/features/mssql/article.phpr/1567611

Bookmarked.

>>In MySQL
>>- PostgreSQL
>>- MSSQL
>>- Interbase
>>- Oracle 8/9
>
> Ik denk dat je even per DB in de documentatie moet zoeken naar
> INFORMATION_SCHEMA (trefwoord: SQL Catalog).

Na wat gegoogled te hebben vraag ik me af of dit wel mt MySQL werkt. Op
de website van MySQL vind ik ook geen info over 'INFORMATION_SCHEMA' :-(

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Rene Pijlman]

Maarten Wierda:
>Rene Pijlman wrote:
>>>Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een database te lezen.
^^^^^^^^^

>Op de e1n of andere manier krijg ik de volgende foutmelding terug als ik
>dit commando uitvoer op mijn MySQL database (versie 3.23.47-nt):
[...]
>Na wat gegoogled te hebben vraag ik me af of dit wel mt MySQL werkt. Op
>de website van MySQL vind ik ook geen info over 'INFORMATION_SCHEMA' :-(

Het werkt niet, maar het is de standaard :-\

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

[Maarten Wierda]

Rene Pijlman wrote:

>>>>Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een database te lezen.
>
> ^^^^^^^^^

[...]

>>Na wat gegoogled te hebben vraag ik me af of dit wel mt MySQL werkt. Op
>>de website van MySQL vind ik ook geen info over 'INFORMATION_SCHEMA' :-(
>
>
> Het werkt niet, maar het is de standaard :-\

Leuk he? Dat SQL :-)

--
Cheers, Maarten Wierda
cp: Dinosaur Jr. - Pointless

"Music is first, lyrics are secondary."

[René]

Maarten Wierda wrote:
> Rene Pijlman wrote:
>
>>>>> Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
>>>>> database te lezen.
>>>>
>>
>> ^^^^^^^^^
>
>
> [...]
>
>>> Na wat gegoogled te hebben vraag ik me af of dit wel mt MySQL werkt.
>>> Op de website van MySQL vind ik ook geen info over
>>> 'INFORMATION_SCHEMA' :-(
>>
>>
>>
>> Het werkt niet, maar het is de standaard :-\
>
>
> Leuk he? Dat SQL :-)
>

Kijk in de MySQL manual; 4.5.7.1 Retrieving information about database,
tables, columns and indexes

http://www.mysql.com/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#SHOW_DAT ABASE_INFO

[Jan Smeelen]

"Maarten Wierda" <moart3nAT@chello.nl> schreef in bericht
news:bi317f$115m$1@nl-news.euro.net...
> Rene Pijlman wrote:
>
> >>Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
> >>database te lezen.
> >
> > SELECT *
> > FROM INFORMATION_SCHEMA.COLUMNS
>
> Op de e1n of andere manier krijg ik de volgende foutmelding terug als ik
> dit commando uitvoer op mijn MySQL database (versie 3.23.47-nt):

Met PHP lukt het me zo :

$fields = mysql_list_fields("$database", "$table");

$columns = mysql_num_fields($fields);
for ($i = 0; $i < $columns; $i++) {
echo mysql_field_name($fields, $i);
}

Mogelijk heb je er iets aan ?

Succes !
Jan Smeelen.
http://www.webfontein.nl

[Maarten Wierda]

René wrote:

[standaard SQL-functie om kolomnamen uit een database te lezen]

[...]

> Kijk in de MySQL manual; 4.5.7.1 Retrieving information about database,
> tables, columns and indexes
> <http://www.mysql.com/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#SHOW_DAT ABASE_INFO>

Deze functie kende ik al. Helaas is deze functie m.i. geen stanaard
SQL-functie, maar een MySQL-functie.

Bedankt.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Maarten Wierda]

Jan Smeelen wrote:

[standaard SQL-functie om kolomnamen uit een database te lezen]

> Met PHP lukt het me zo :
>
> $fields = mysql_list_fields("$database", "$table");
>
> $columns = mysql_num_fields($fields);
> for ($i = 0; $i < $columns; $i++) {
> echo mysql_field_name($fields, $i);
> }
>
> Mogelijk heb je er iets aan ?

Nee, helaas. Ik ben op zoek naar een standaard SQL-functie. Dit is een
oplossing die alleen werkt bij MySQL-databases.

Bedankt.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Maarten van der Peet]

Maarten Wierda <moart3n@norecessDOT.com> wrote:

> Hoi n.i.w.s-s,
>
> Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
> database te lezen.
>
> In MySQL is dit mogelijk met de functie SHOW
> <http://www.mysql.com/doc/en/SHOW.html>. Nu is het de bedoeling dat ik
> een soortgelijke functie vind die ik ook kan gebruiken in andere
> SQL-databases:
>
> - PostgreSQL
> - MSSQL
> - Interbase
> - Oracle 8/9
>
> Kan iemand mij hiermee op weg helpen? Alvast bedankt voor de evt.
> reacties.

Die functie bestaat niet. Althans de SQL-"standaard" wordt niet in MySQL
geïmplementeerd.

Verder:
Uit het MySQL Cookbook, hoofdstuk 9: Obtaining and Using Metadata:

Problem:
You want a way to get table information that doesn't use MySQL -specifc
queries like SHOW COLUMNS
Solution:
This isn't possible for all APIs. Ond exeption is JDBC, which provides a
standard interface to table metadata.

Uit de probleemomschrijving blijkt dat SHOW COLUMNS MySQL-specifiek is.


--
Maarten van der Peet

[Maarten Wierda]

Maarten van der Peet wrote:

> > Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
> > database te lezen.

[...]

> Die functie bestaat niet. Althans de SQL-"standaard" wordt niet in MySQL
> geïmplementeerd.
>
> Verder:
> Uit het MySQL Cookbook, hoofdstuk 9: Obtaining and Using Metadata:
>
> Problem:
> You want a way to get table information that doesn't use MySQL -specifc
> queries like SHOW COLUMNS
> Solution:
> This isn't possible for all APIs. Ond exeption is JDBC, which provides a
> standard interface to table metadata.
>
> Uit de probleemomschrijving blijkt dat SHOW COLUMNS MySQL-specifiek is.

Helaas, dan gaan we op zoek naar iets anders, wellicht een aanpassing in
het database-model. Vriendelijk bedankt voor de bruikbare informatie!

--
Cheers, Maarten Wierda
cp: DJ Photek

"Music is first, lyrics are secondary."

[Gerbrand van Dieijen]

On Fri, 22 Aug 2003 12:47:02 +0200, Maarten Wierda wrote:

>Helaas, dan gaan we op zoek naar iets anders, wellicht een aanpassing in
>het database-model. Vriendelijk bedankt voor de bruikbare informatie!
>

Aanpassing in het databasemodel !? :-/

Het lijkt me niet goed dat je een functie om kolomnamen te bekijken nodig
hebt in je databasemodel, je hebt dan waarschijnlijk iets van:
Tabel
attr. 1 attr 2. attr3 etc.
(b.v. Tabel LeerlingPietje,Nederlands,Natuurkunde,Wiskunde,Fra ns,Engels,
met als waarde alle cijfers voor ieder vak).
Waar af en toe een attribuut bijkomt of vanaf gaat.

Je kunt beter dan een ander databasemodel gebruiken:

Tabel Leerling->Naam,etc NAW,LeerlingId
Tabel Vak->Naam,VakId
Tabel Resultaat->LeerlingId,VakId,Cijfer

Waar in het Tabel resultaat de lijst van resultaten van alle leerlingen
van alle vakken kan komen te staan, die je met een join query (SELECT ..
FROM) eruit kunt halen.
Algemeen is dit een 'many to many' relatie


--
Gerbrand van Dieijen

WWW: http://twisted.warande.net
ICQ: 19345450

[Gerbrand van Dieijen]

On Fri, 22 Aug 2003 12:22:39 +0200, Maarten van der Peet wrote:
>You want a way to get table information that doesn't use MySQL -specifc
>queries like SHOW COLUMNS
>Solution:
>This isn't possible for all APIs. Ond exeption is JDBC, which provides a
>standard interface to table metadata.
>
>Uit de probleemomschrijving blijkt dat SHOW COLUMNS MySQL-specifiek is.
>

Zoals in de DOC staat is SQL hier gewoon te beperkt voor, maar je kunt wel
JDBC gebruiken, dit is ook een algemene standaard, praktisch iedere
database heeft wel een jdbcdriver (die je ook dynamisch kunt laden).
Je kunt ook ODBC gebruiken, dat is ook een standaard maar meer (echter
niet uitsluitend) Windows gericht.
Verder heb je voor Perl ook PerlDBI (zelf geen ervaring mee), dat is geen
echte standaard maar er zijn wel een hoop drivers daarvoor.



--
Gerbrand van Dieijen

WWW: http://twisted.warande.net
ICQ: 19345450

[Maarten Wierda]

Gerbrand van Dieijen wrote:

>>Helaas, dan gaan we op zoek naar iets anders, wellicht een aanpassing in
>>het database-model. Vriendelijk bedankt voor de bruikbare informatie!
>
> Aanpassing in het databasemodel !? :-/

<snip>

> Je kunt beter dan een ander databasemodel gebruiken:
>
> Tabel Leerling->Naam,etc NAW,LeerlingId
> Tabel Vak->Naam,VakId
> Tabel Resultaat->LeerlingId,VakId,Cijfer

Ik ken de regels ongeveer, ik weet ook de basisregels van ERM. Wat je
hierboven schetst klinkt me dus bekend in de oren.

> Waar in het Tabel resultaat de lijst van resultaten van alle leerlingen
> van alle vakken kan komen te staan, die je met een join query (SELECT ..
> FROM) eruit kunt halen.
> Algemeen is dit een 'many to many' relatie

En ik weet ook dat koppeltabellen dan (veel-op-veel) op z'n plaats zijn :-)

Deze vraag is overigens met name namens collega die zijn afstudeerstage
bij ons volgt, maar ik vind het ook wel leuk om mee te denken. Ik zal
even de situatie proberen te verwoorden (uit m'n hoofd):

Er is een tabel 'subscribers'. In deze tabel bevinden zich een aantal
kolommen zoals name, address, postal_code etc.

Nu zijn er klanten (die van het betreffende systeem gebruik maken) die
meer informatie willen opslaan van hun abonees (subscribers). Daarom is
er een extra tabel gemaakt ('subscriber_extraFields' o.i.d.) waarin zich
een x-aantal boolean-, integer-, double- en char-kolommen bevinden (kan
iets afwijken).

In deze tabel wordt een 'subscriberID' opgeslagen zodat bekend is welke
extra informatie bij welke abonnee hoort (bijv. schoenmaat).

Indien er bijv. 10 kolommen van het type INT zijn, en een klant wilt 12
kolommen van dit type hebben, willen we dynamisch extra kolommen kunnen
aanmaken. En het moet dit in in SQL afgehandel worden, en niet in PHP.

Er is voor deze extra tabel gekozen, omdat er anders heel veel extra
kolommen komen in de subscriber-tabel die niet op alle abonnees van
toepassing zijn, wat wellicht voor onnodig veel overload kan zorgen.

<gedachtengang>
Hier moet ik overigens nog eens goed over nadenken, want indien je
correcte SELECT-queries uitvoert, hoeft dat IMHO niet voor overload te
zorgen.
</gedachtengang>

Maandag zal ik een ERM-model online zetten in de URL in dit draadje
vermelden.

--
Cheers, Maarten Wierda
cp: The Ramones - The KKK Took My Baby Away

"Music is first, lyrics are secondary."

[Maarten Wierda]

Gerbrand van Dieijen wrote:

>>Uit de probleemomschrijving blijkt dat SHOW COLUMNS MySQL-specifiek is.
>
> Zoals in de DOC staat is SQL hier gewoon te beperkt voor,

Yep, helaas.

> maar je kunt wel
> JDBC gebruiken, dit is ook een algemene standaard, praktisch iedere
> database heeft wel een jdbcdriver (die je ook dynamisch kunt laden).
> Je kunt ook ODBC gebruiken, dat is ook een standaard maar meer (echter
> niet uitsluitend) Windows gericht.

Er is voor het betreffende project al een keuze gemaakt om SQL te
gebruiken, omdat hier al kennis van aanwezig was. Je blijft tijdens het
ontwikkelen echter altijd op een aantal probleempjes stuiten.

> Verder heb je voor Perl ook PerlDBI (zelf geen ervaring mee), dat is geen
> echte standaard maar er zijn wel een hoop drivers daarvoor.

Het is met oog op de toekomst in ieder geval iets om mee te nemen en
serieus over na te denken. Bedankt voor het meedenken!

--
Cheers, Maarten Wierda
cp: Supergrass - Jesus Came From Outer Space

"Music is first, lyrics are secondary."

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> maar je kunt wel JDBC gebruiken, dit is ook een algemene standaard,
>> praktisch iedere database heeft wel een jdbcdriver (die je ook
>> dynamisch kunt laden). Je kunt ook ODBC gebruiken, dat is ook een
>> standaard maar meer (echter niet uitsluitend) Windows gericht.
>
> Er is voor het betreffende project al een keuze gemaakt om SQL te
> gebruiken, omdat hier al kennis van aanwezig was. Je blijft tijdens
> het ontwikkelen echter altijd op een aantal probleempjes stuiten.

Deze opmerking snap ik niet, er wordt enkele info gegeven over database
abstractie lagen en je geeft als opmerking dat er reeds gekozen is voor
SQL! Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
echter die abstractie lagen voegen nog enkele dingen toe en eentje
daarvan is het opvragen van informatie over de gebruiker database/table,
iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
dus wel te benaderen met bv een [JO]DBC driver. Je zal dan ook meer
success hebben in het vinden van een oplossing indien je je niet
concentreert op het vinden van 1 SQL query welke overal werkt maar met
het zoeken naar een abstractielaag welke deze informatie voor te
gebruikern dabaseengines kan achterhalen.

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

>>>maar je kunt wel JDBC gebruiken, dit is ook een algemene standaard,
>>>praktisch iedere database heeft wel een jdbcdriver (die je ook
>>>dynamisch kunt laden). Je kunt ook ODBC gebruiken, dat is ook een
>>>standaard maar meer (echter niet uitsluitend) Windows gericht.
>>
>>Er is voor het betreffende project al een keuze gemaakt om SQL te
>>gebruiken, omdat hier al kennis van aanwezig was.

<snip>

> Deze opmerking snap ik niet, er wordt enkele info gegeven over database
> abstractie lagen en je geeft als opmerking dat er reeds gekozen is voor
> SQL!

Uhm, ja.. :?

> Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
> echter die abstractie lagen voegen nog enkele dingen toe en eentje
> daarvan is het opvragen van informatie over de gebruiker database/table,
> iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
> dus wel te benaderen met bv een [JO]DBC driver.

Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
doen betreft '[JO]DBC'. Het liefst vind ik echter een oplossing voor het
databasemodel.

> Je zal dan ook meer
> success hebben in het vinden van een oplossing indien je je niet
> concentreert op het vinden van 1 SQL query welke overal werkt maar met
> het zoeken naar een abstractielaag welke deze informatie voor te
> gebruikern dabaseengines kan achterhalen.

Duidelijk. Vriendelijk bedankt.

--
Cheers, Maarten Wierda
cp: Animals - It's My Life

"Music is first, lyrics are secondary."

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
>> echter die abstractie lagen voegen nog enkele dingen toe en eentje
>> daarvan is het opvragen van informatie over de gebruiker database/table,
>> iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
>> dus wel te benaderen met bv een [JO]DBC driver.
>
> Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
> post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
> doen betreft '[JO]DBC'.

Met wat en hoe doen jullie het nu eigenlijk?

> Het liefst vind ik echter een oplossing voor het
> databasemodel.

Of beter gezegt: het gebrek aan (een statisch) (een statisch) (een
statisch) (een statisch) (een statisch) (een statisch) (een statisch)
(een statisch) (een statisch) datamodel :)

Ik zou zelf denken aan een tabel per extra optie, ik heb echter geen
idee wat de performance impact is en of je uberhaupt makkelijk/portable
het bestaan van tabellen kan controleren.

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

>>>Met bv [JO]DBC kan je gewoon SQL lullen tegen een database,
>>>echter die abstractie lagen voegen nog enkele dingen toe en eentje
>>>daarvan is het opvragen van informatie over de gebruiker database/table,
>>>iets wat ogenschijnlijk niet in standaard SQL terug te vinden is maar
>>>dus wel te benaderen met bv een [JO]DBC driver.
>>
>>Aha, dat wist ik niet. Achteraf gezien begrijp ik je reactie op m'n
>>post. Excusez moi. Maandag ga ik, of een collega, wel even wat research
>>doen betreft '[JO]DBC'.
>
> Met wat en hoe doen jullie het nu eigenlijk?

We gebruiken nu een een PHP-klasse, ezSQL.

"ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
MS-SQL database(s) within your PHP/C++ scripts."

>> Het liefst vind ik echter een oplossing voor het
>> databasemodel.
>
> Of beter gezegt: het gebrek aan (een statisch) (een statisch) (een
> statisch) (een statisch) (een statisch) (een statisch) (een statisch)
> (een statisch) (een statisch) datamodel :)

Uiteraard :-)

> Ik zou zelf denken aan een tabel per extra optie, ik heb echter geen
> idee wat de performance impact is en of je uberhaupt makkelijk/portable
> het bestaan van tabellen kan controleren.

Dat is misschien nog wel een beter optie inderdaad. Indien een klant
extra informatie wilt opnemen in de subscriber-tabel, een extra tabel
aanmaken met de betreffende velden. In ieder geval zeker iets om in
overweging te nemen.

Bedankt voor het meedenken.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Daniel Tryba]

Maarten Wierda <moart3nAT@chello.nl> wrote:
>> Met wat en hoe doen jullie het nu eigenlijk?
>
> We gebruiken nu een een PHP-klasse, ezSQL.
>
> "ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
> Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
> MS-SQL database(s) within your PHP/C++ scripts."

Dit class klinkt wel heel erg simpel als ik naar de documentatie pagina
kijk (doet niet veel meer dan de databse specifieke calls encapsulaten
en de laatste query bewaren). Als je bv eens kijkt naar Metabase (geen
ervaring mee), dan beweren ze dat:
<q>
Schema reverse engineering

Despite Metabase provides schema creation and maintenance support
functions, the Metabase API functions can also access databases that
were created by some other process. However, it is recommended that you
install database schemas with Metabase manager to use with your database
applications based on Metabase API.

[knip]

$success=MetabaseListTables($database, $tables)
Purpose

Retrieve the list of tables in the current database.

[knip]

$success=MetabaseListTableFields($database, $table, $fields)
Purpose

Retrieve the list of fields of a given table of the current database.
</q>

Er staat nog ergens het woordje expirimental ertussen :)

--

Daniel Tryba

[Maarten Wierda]

Daniel Tryba wrote:

> > We gebruiken nu een een PHP-klasse, ezSQL.
> >
> > "ezSQL is a widget that makes it ridiculously easy for you to use mySQL,
> > Oracle8, InterBase/FireBird, PostgreSQL, SQLite (PHP), SQLite (C++) or
> > MS-SQL database(s) within your PHP/C++ scripts."
>
> Dit class klinkt wel heel erg simpel als ik naar de documentatie pagina
> kijk (doet niet veel meer dan de databse specifieke calls encapsulaten
> en de laatste query bewaren).

Veel meer hebben we ook niet nodig, behalve dan.. :-)

> Als je bv eens kijkt naar Metabase (geen
> ervaring mee), dan beweren ze dat:
> <q>
> Schema reverse engineering
>
> Despite Metabase provides schema creation and maintenance support
> functions, the Metabase API functions can also access databases that
> were created by some other process. However, it is recommended that you
> install database schemas with Metabase manager to use with your database
> applications based on Metabase API.

Van Manuel Lemos, ik ken de schrijver (van phpclasses.org) en ik ken de
class ook.

> [knip]
>
> $success=MetabaseListTables($database, $tables)
> Purpose
>
> Retrieve the list of tables in the current database.
>
> [knip]
>
> $success=MetabaseListTableFields($database, $table, $fields)
> Purpose
>
> Retrieve the list of fields of a given table of the current database.
> </q>
>
> Er staat nog ergens het woordje expirimental ertussen :)

Ik ga even kijken. Bedankt.

--
Cheers, Maarten Wierda

"Music is first, lyrics are secondary."

[Hugo Pragt]

DESCRIBE


Hugo


"Maarten Wierda" <moart3n@norecessDOT.com> wrote in message
news:3F44D6B4.7FB26222@norecessDOT.com...
> Hoi n.i.w.s-s,
>
> Ik ben op zoek naar een standaard SQL-functie om kolomnamen uit een
> database te lezen.
>
> In MySQL is dit mogelijk met de functie SHOW
> <http://www.mysql.com/doc/en/SHOW.html>. Nu is het de bedoeling dat ik
> een soortgelijke functie vind die ik ook kan gebruiken in andere
> SQL-databases:
>
> - PostgreSQL
> - MSSQL
> - Interbase
> - Oracle 8/9
>
> Kan iemand mij hiermee op weg helpen? Alvast bedankt voor de evt.
> reacties.
>
> --
> Cheers, Maarten Wierda
>
> "Music is first, lyrics are secondary."