[Gambas-user] DB compatible to SQL Server 2000

ron ronstk at ...239...
Mon Aug 30 15:51:49 CEST 2004


On Monday 30 August 2004 11:01, Benoit Minisini wrote:
> On Monday 30 August 2004 10:45, ron wrote:
> > On Monday 30 August 2004 10:05, Benoit Minisini wrote:
> > > On Monday 30 August 2004 03:54, Iwan Prasetyo wrote:

snip

> > >
> > > Regards,
> >
> > May be you can use the AdoDB in PHP as a example to
> > get support for all kinds of DB's.
> > After all it is doing the same as we need in gambas for php.
> >
> > Even more interesting a interface to the AdoDB class
> > That way you do not have to write new support for the
> > different db's but only on one interface, the gb.AdoDB.
> 
> How could you use a PHP module in Gambas ???
> 

I want to refer to the AdoDB PHP class as a lookup source for 
creating the new ODBC component code.

But for the question, Yes it can.
Create a PHP page to access the database using AdoDB class.
Insert in the page the code to get the database/tables and if the 
database supports stored queries to get them.
Let the page write the result in a text file, maybe with a equivalent 
layout the Result class now in the gb.db component, and place the php
script in the webservers documentroot path.

A php page using the AdoDB class and code to get the required
tables, queries, schema, catalog etc.
Put it in the webservers document path and call it as a webpage 
with the gb.net component. Interpret the result and done.
This could be the job of the gb.adodb component. :)
I know sound stupid but it is a way.

This way it is more easy with windows while it is possible to
use PHP without the webserver, it can run as CGI component on win
on the dos command line and result to standard out.
As far I know ATM you can't use the php service directly in linux like CGI.

Another way is using gambas itself.
A gambas app can make the required page, put it on correct place,
using the gb.net component calling the webserver, geting the result, 
interpret the result and extract the required info passing it back
to the out pipe/stdout.
This app should the act as the gb.odbc :) :) :)

Not direct useless but make no sense to do it this way.

We need a real C program to load the mod_php and present it the script
and let php does his work witch gives the required result back and 
pass that result back. In this case to gambas of course.
Less useless, a bit more sense, can be used by more end applications.

I do not prefer this way but "How is answered" :)

> >
> > I got several years back the ODBC developres kit.
> > Didn't see it now for long time.
> > It contains a quicktest program using mutch of the
> > sql commands. Source in C to build and execute them
> > to test the ODBC function of the driver works.
> >
> 
> The more difficult is not getting the result of a query, it is getting 
> metadata information (named catalog queries in ODBC).
> 

Here I get some problems.
What exactly is catalog and what are schema?
Are the the same or are they different?
I found in the past time so many explanations I'm lost with it.

When I use SQLyog, the give for schema the layout of
the database, containing tables, fields and stored queries.

Mainly in MS documentation I see the name Catalog and
it look to me MySQL is using Schema.

The stored Queries can you find in MSaccess databases (*.mdb)
You can link to these in another database as a table.
Then we have stored Functions and stored Procedures.

Stored Querys act as a Table. You can ask them to get a part of the table
without using the query yourself, it is in the database.
Stored Functions are user created Functions like a gambas function 
to get data from a table or something to let a number field return 
the text 'yes'/'no' depending the number.

Stored Procedures are procedures to execute at server site to
do many things with one request on or to the server. 
A chain of select/update and delete queries across 1 or more tables
Some of them are MsSQL and some are MySQL or other DB engines.

As far I know it is all stored in system tables of the database and/or the server.
Also I could see in a ODBC only programm these layout and system tables
at the company I worked for. It was a program to monitor changes in tables.
A debugging tool.

I understand for now this is the metadata you refer to.
Forgive me when I'm wrong.

> If I made my own cooking with the gambas database component, it was for two 
> reasons: Gambas datatype support was needed for the ease of programming, and, 
> above all, all database interfaces I saw didn't please me.
> 
> I find the odbtp approach a very good idea :-)
> 

I agree with that but have some reservations.

The question is what we want. Using MsSQL server, SQL Server200 and MySQL?
That can be done on windows with ODBC and when I'm right I have seen
a linux variant to reach the MS stuff. MySQL is no problem for linux based.

But we are on the linux platform and want to get from MS platform.
For SQL servers it is already posible with unixODBC at http://www.unixodbc.org/
It can show/deliver the layout(metadata) and support many(over 25) DB types.
For MS people going to *nix it is more friendly i think as ODBTP and
*nix people don't use MS stuf :) ( wrong, I know)
The most importand thing is for the windows machines no install of any software needed.

Using ODBTP has the advantage to get the *.mdb on line across TCP.
It requires however the ODBTP server software installed and runs only
on NT4, XP and 2000. Not every one have it or want/can install the server.

Using ODBTP to get from *nix requires the client software. 
That requires to have MS VC6++. Also not available for everyone but less
importand from gambas view point.
For MySQL there is already ODBC so no need for ODBTP.

There is however one very good thing with ODBTP I like very much but can't use.
It serves the *.mdb files direct across TCP.
It can only not do it stand alone or can they read *.mdb files? 
It must use the ODBC interface on the windows machine or use the
MSSQL server with a linked table on a Access database.
When the last is done then we can use ODBC also for the *.mdb files
by connecting to the SQL server and no install software needed

Seen for this install requirements I think unixODBC is also a good thing to use.
It is not the win to *nix sql but *nix to win that is/was difficult.
The approach of ODBPT is indeed nice but I think unixODBC can be a better choise
and it support more data source objects, not only the MS ones.
And for the windows side, al what is need is already in it.

Same as above. Forgive me when I'm wrong.
And of course it is you choice to decide.


> Regards,
> 
My 2 cents.


More information about the User mailing list