Hello Pierre-Henri,

If I am not mistaken that you mentioned that somebody developed a Sybase
driver sometime. If so, who did it? Would that person be willing to
contribute with the driver code? I would like to know because there is
another developer willing to develop the Sybase driver for Metabase and
if there is one already it would be pointless to duplicate efforts.

Regards,
Manuel Lemos

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/metabase_interface.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase Interface with result set bulk data fetching functions

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/metabase_interface.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/metabase_database.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase driver base class with result set bulk data fetching
functions

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/metabase_database.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

I finally made time to integrate the result set bulk data fecthing
functions contributed by Lukas Smith and his partner.

I have just uploaded them to the beta files section as you may have
noticed by the notification sent by the list before.

Basically the functions do:

- Fecth a single value from the first row and first column and free the
result set.

- Fetch an arbitrary row of the result set.

- Fetch the first row into an array and free the result set.

- Fetch the first column of all rows into an array and free the result
set.

- Fetch the whole result set into a 2 dimensional array and free the
result set.

Optionally data type conversion may be performed (or not) according ta
list of result column types specified before fetching using another new
function. If this function is not used, no conversion is done so no
overhead is added. This is to be optimized if your result set only
contains text or integers that obviously do not need conversion.

These functions are not yet tested, optimized for any of the databases
nor documented. I will do that tomorrow.

Lukas, please take a look at the new code and see if that looks ok for
you and please provide some feedback ASAP so I can release this on
January 18th, Metabase's second aniversary since its first public
release. I will also want to add Sybase driver contributed by Sergio Zia
and a surprise feature that I am testing and hopefully will be ready for
this release too.

To make this work, changes were need in the driver classes but I did not
uploaded them because I still need to optimize the functions to fetch
rows into arrays for each database. I will do it tomorrow.

When I document this, I will also would like to add the credits in
Metabase manual to you and your partner for contributing with the bulk
data fetching code, as I do with everybody that contributes to Metabase,
but I need you to tell me the names and e-mail addresses that you would
like to show in the manual.

Regards,
Manuel Lemos

Ok a quick answer.
I will look over it all some more.

1) How fast is mysql_result() ?
It does give more flexibility since this allowed you to implement some
more flexibility than mysql_fetch_row (or fetch_fetch_array).

2) You could actually also let the user specify the column to fetch when
you make use of mysql_result.

3) $success=$this->SetError("Fetch field","result set is empty");
you could also check that in the column and all fetch function
I think it important to always offer the same level of detail on errors
for all functions

4) In FetchResultRow:
What happends if I do not set a row?

5) In the Convertfunctions:
Function ConvertResult(&$value,$type)
Function ConvertResultRow($result,&$row)

Wouldn't it be nicer to move the switch statement from ConvertResultRow
into ConvertResult. This would also allow you to get rid of the same
switch statement in the Field and Column Fetch function

6) One feature that was important for me is to be able to reduce the
amount of function calls in the way I have done with the optional
parameters when sending a query. Will you also implement this in the db
specific drivers?

7) Name/Email:
Christopher Linn (clinn@...)
Lukas Smith (smith@...)

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: mlemos@... [mailto:mlemos@...] On
Behalf
> Of Manuel Lemos
> Sent: Wednesday, January 16, 2002 7:25 AM
> To: metabase-dev@yahoogroups.com
> Subject: [metabase-dev] New result set bulk data fetching functions
>
> Hello,
>
> I finally made time to integrate the result set bulk data fecthing
> functions contributed by Lukas Smith and his partner.
>
> I have just uploaded them to the beta files section as you may have
> noticed by the notification sent by the list before.
>
> Basically the functions do:
>
> - Fecth a single value from the first row and first column and free
the
> result set.
>
> - Fetch an arbitrary row of the result set.
>
> - Fetch the first row into an array and free the result set.
>
> - Fetch the first column of all rows into an array and free the result
> set.
>
> - Fetch the whole result set into a 2 dimensional array and free the
> result set.
>
> Optionally data type conversion may be performed (or not) according ta
> list of result column types specified before fetching using another
new
> function. If this function is not used, no conversion is done so no
> overhead is added. This is to be optimized if your result set only
> contains text or integers that obviously do not need conversion.
>
> These functions are not yet tested, optimized for any of the databases
> nor documented. I will do that tomorrow.
>
> Lukas, please take a look at the new code and see if that looks ok for
> you and please provide some feedback ASAP so I can release this on
> January 18th, Metabase's second aniversary since its first public
> release. I will also want to add Sybase driver contributed by Sergio
Zia
> and a surprise feature that I am testing and hopefully will be ready
for
> this release too.
>
> To make this work, changes were need in the driver classes but I did
not
> uploaded them because I still need to optimize the functions to fetch
> rows into arrays for each database. I will do it tomorrow.
>
> When I document this, I will also would like to add the credits in
> Metabase manual to you and your partner for contributing with the bulk
> data fetching code, as I do with everybody that contributes to
Metabase,
> but I need you to tell me the names and e-mail addresses that you
would
> like to show in the manual.
>
> Regards,
> Manuel Lemos
>
> ------------------------ Yahoo! Groups Sponsor
>
> To Unsubscribe, send a blank message to: metabase-dev-
> unsubscribe@eGroups.com
> Need other Metabase drivers? http://www.egroups.com/surveys/metabase-
> dev?id=263873
> Latest beta version: http://www.egroups.com/files/metabase-dev
> Vote on Metabase: http://www.zend.com/apps.php?id=122&single=1
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>

Hello,

Lukas Smith wrote:
>
> Ok a quick answer.
> I will look over it all some more.
>
> 1) How fast is mysql_result() ?
> It does give more flexibility since this allowed you to implement some
> more flexibility than mysql_fetch_row (or fetch_fetch_array).
>
> 2) You could actually also let the user specify the column to fetch when
> you make use of mysql_result.

I am not sure why you ask, but MySQL driver is optimized to fecth whole
rows at once. I just haven't uploaded it yet. As you wrote, these
functios were added to Metabase to maximize performance over
flexibility.


> 3) $success=$this->SetError("Fetch field","result set is empty");
> you could also check that in the column and all fetch function
> I think it important to always offer the same level of detail on errors
> for all functions

I the case of FetchResultField and FetchResultRow, I understood the
caller assumes there is a at least one row of results. If the assumption
is not valid it returns an error. In the case of FecthResultColumn and
FetchResultAll, it may be a valid situation where there are no rows to
retrieve, so no error is triggered in that case and an empty array is
returned.


> 4) In FetchResultRow:
> What happends if I do not set a row?

The row parameter is an array to be passed by reference in which the
result row is stored, not a row number.


> 5) In the Convertfunctions:
> Function ConvertResult(&$value,$type)
> Function ConvertResultRow($result,&$row)
>
> Wouldn't it be nicer to move the switch statement from ConvertResultRow
> into ConvertResult. This would also allow you to get rid of the same
> switch statement in the Field and Column Fetch function

That was done for performance reasons. There is no point in going
through the overhead of calling ConvertResult if the type is text (no
conversion) or integer (always intval($value)).


> 6) One feature that was important for me is to be able to reduce the
> amount of function calls in the way I have done with the optional
> parameters when sending a query. Will you also implement this in the db
> specific drivers?

Yes, I thought of that I I think that is cleaner to be done with another
set of functions to wrap around the ones that were just added. I could
have added them, but in the comments you mentioned there would be more
functions to add so I assumed it would be those. I will add them now.

Regards,
Manuel Lemos

> > 1) How fast is mysql_result() ?
> > It does give more flexibility since this allowed you to implement
some
> > more flexibility than mysql_fetch_row (or fetch_fetch_array).
> >
> > 2) You could actually also let the user specify the column to fetch
when
> > you make use of mysql_result.
>
> I am not sure why you ask, but MySQL driver is optimized to fecth
whole
> rows at once. I just haven't uploaded it yet. As you wrote, these
> functios were added to Metabase to maximize performance over
> flexibility.

The reason I ask is because the patch i submitted used mysql_fetch_row
(or mysql_fetch_array ... I don't remember).
These might be faster but do not allow you quite as much flexiblity as
mysql_result does. So you will implement a FetchResultArray based on
mysql_fetch_row for the mysql driver (and the respective alternatives
for the other DBs if avaiable?)

> > 3) $success=$this->SetError("Fetch field","result set is empty");
> > you could also check that in the column and all fetch function
> > I think it important to always offer the same level of detail on
errors
> > for all functions
>
> I the case of FetchResultField and FetchResultRow, I understood the
> caller assumes there is a at least one row of results. If the
assumption
> is not valid it returns an error. In the case of FecthResultColumn and
> FetchResultAll, it may be a valid situation where there are no rows to
> retrieve, so no error is triggered in that case and an empty array is
> returned.
>

Hmm ... not really ... the assumption is more about what data the caller
is interested in. So in FetchResultField the caller is only interested
in the first cell (and he should model is query accordingly). In the
case of FetchResultField the caller probably modeled a query where he
gets part of a column returned.

This ties in with my comments 1) and 2) ... actually it makes sense to
write the query so you only get the data you need and you choose a fetch
method accordingly. Therefore we never really needed the flexibility to
specify which row to fetch etc. my comment was confusing because I
miss-read the FetchResultRow function (see my comment in this mail
regarding 4) )

So the important question for me is the one I asked above: Will you use
mysql_fetch_row or not?

The other question is about error handling. If an empty result set is a
problem or not will be upto the caller but in either case I think it
might be interesting to know why the variable that was passed by
references remains empty.

> > 4) In FetchResultRow:
> > What happends if I do not set a row?
>
> The row parameter is an array to be passed by reference in which the
> result row is stored, not a row number.

Doh! .. got confused .. ignore my comment :-)

> > 5) In the Convertfunctions:
> > Function ConvertResult(&$value,$type)
> > Function ConvertResultRow($result,&$row)
> >
> > Wouldn't it be nicer to move the switch statement from
ConvertResultRow
> > into ConvertResult. This would also allow you to get rid of the same
> > switch statement in the Field and Column Fetch function
>
> That was done for performance reasons. There is no point in going
> through the overhead of calling ConvertResult if the type is text (no
> conversion) or integer (always intval($value)).

Yeah .. the only problem is that now you have the same code in various
places which might not be as nice to maintain.

Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Hi,

a general question:
Is there a particular reason why every sequence has its own table in the
mysql sequence emulation?
Is this just to make it more transparent what sequences exist?
Is this for performance reasons?
Is this just a more standard way of doing it?

Best regards,
Lukas Smith
smith@...
_______________________________
 DybNet Internet Solutions GbR
 Alt Moabit 89
 10559 Berlin
 Germany
 Tel. : +49 30 83 22 50 00
 Fax : +49 30 83 22 50 07
 www.dybnet.de info@...
_______________________________

Hello,

Lukas Smith wrote:
>
> Hi,
>
> a general question:
> Is there a particular reason why every sequence has its own table in the
> mysql sequence emulation?
> Is this just to make it more transparent what sequences exist?
> Is this for performance reasons?
> Is this just a more standard way of doing it?

Auto-increment fields have to be primary keys. Anyway, smaller tables
are faster to access, so like in databases that support real sequences,
those are separate objects in no way attached to any tables.

Regards,
Manuel Lemos

Yeah, so performance is the reason. Which is a good reason too :-)
Using "SELECT .. .FOR UPDATE" would probably be a lot slower
Anyways my two co-workers were complaing about the growing number of
tables :-)

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

> -----Original Message-----
> From: mlemos@... [mailto:mlemos@...]
On
> Behalf Of Manuel Lemos
> Sent: Wednesday, January 16, 2002 7:25 PM
> To: metabase-dev@yahoogroups.com
> Subject: Re: [metabase-dev] sequences
>
> Hello,
>
> Lukas Smith wrote:
> >
> > Hi,
> >
> > a general question:
> > Is there a particular reason why every sequence has its own table in
the
> > mysql sequence emulation?
> > Is this just to make it more transparent what sequences exist?
> > Is this for performance reasons?
> > Is this just a more standard way of doing it?
>
> Auto-increment fields have to be primary keys. Anyway, smaller tables
> are faster to access, so like in databases that support real
sequences,
> those are separate objects in no way attached to any tables.
>
> Regards,
> Manuel Lemos
>
> To Unsubscribe, send a blank message to: metabase-dev-
> unsubscribe@eGroups.com
> Need other Metabase drivers? http://www.egroups.com/surveys/metabase-
> dev?id=263873
> Latest beta version: http://www.egroups.com/files/metabase-dev
> Vote on Metabase: http://www.zend.com/apps.php?id=122&single=1
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>

Hello,

Lukas Smith wrote:
>
> Yeah, so performance is the reason. Which is a good reason too :-)

Actually the main reason is that you can only have one auto-increment
field per table.

> Using "SELECT .. .FOR UPDATE" would probably be a lot slower
> Anyways my two co-workers were complaing about the growing number of
> tables :-)

I see. The greatest problem is that not all databases support
auto-increment fields so resorting to using them in your applications
would lead to non portable applications, thus there would be no great
point to use Metabase.

Regards,
Manuel Lemos

Hello,

--- In metabase-dev@y..., "Lukas Smith" <smith@d...> wrote:
> > > 1) How fast is mysql_result() ?
> > > It does give more flexibility since this allowed you to implement
> some
> > > more flexibility than mysql_fetch_row (or fetch_fetch_array).
> > >
> > > 2) You could actually also let the user specify the column to fetch
> when
> > > you make use of mysql_result.
> >
> > I am not sure why you ask, but MySQL driver is optimized to fecth
> whole
> > rows at once. I just haven't uploaded it yet. As you wrote, these
> > functios were added to Metabase to maximize performance over
> > flexibility.
>
> The reason I ask is because the patch i submitted used mysql_fetch_row
> (or mysql_fetch_array ... I don't remember).
> These might be faster but do not allow you quite as much flexiblity as
> mysql_result does. So you will implement a FetchResultArray based on
> mysql_fetch_row for the mysql driver (and the respective alternatives
> for the other DBs if avaiable?)

Of course, as I said that is done but I haven't uploaded it yet because I want
to pass that through the driver test conformance script that I still need a test
case for this. Don't worry, I will upload that later today.


> The other question is about error handling. If an empty result set is a
> problem or not will be upto the caller but in either case I think it
> might be interesting to know why the variable that was passed by
> references remains empty.

That is not ambiguous. If it FetchResultColumn or FecthResultAll return an empty
array, it is because the returned result set was really empty. This may not be
an error for the programmer.

Now, for FetchResultField or FetchResultRow, it only makes sense to get the
first field or row if there is at least one row in the result set. If there is
none, the programmer could not deduct that from the returned field or row array
values, so that is why the function fails in error in this case as these
functions should only be used to process queries that always return a result
row, so if it was not a programmer but, it must have been a fault in the
communication with the database that cause premature end of result set.



> > > 5) In the Convertfunctions:
> > > Function ConvertResult(&$value,$type)
> > > Function ConvertResultRow($result,&$row)
> > >
> > > Wouldn't it be nicer to move the switch statement from
> ConvertResultRow
> > > into ConvertResult. This would also allow you to get rid of the same
> > > switch statement in the Field and Column Fetch function
> >
> > That was done for performance reasons. There is no point in going
> > through the overhead of calling ConvertResult if the type is text (no
> > conversion) or integer (always intval($value)).
>
> Yeah .. the only problem is that now you have the same code in various
> places which might not be as nice to maintain.

It is a trade-off for speed.

Regards,
Manuel Lemos

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/metabase_database.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase driver base class with result set bulk data fetching
functions

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/metabase_database.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/metabase_interface.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase interface with result set bulk data fetching
functions

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/metabase_interface.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/metabase_mysql.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase MySQL driver with support for retrieving whole row data
at once

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/metabase_mysql.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

I have just uploaded new files with the support for result set bulk data
fetch.

- I added 4 convinience functions that execute the query and fetch a
field, a row, a column and all data from a result set.

- Updated the driver test conformance script to verify if all these
functions are indeed working (and they do after a lost of bug
exorcizing).

- Optimized the MySQL driver to fetch whole rows at once.

Lukas, can you please check this now with you partner? Thanks.


What is left is to optimize the other drivers to fetch whole rows at
once although they already do that internally, verify if these new
functions handle NULLs properly and document the new functionality.

I may not have time to integrate the Sybase driver that Sergio Zia
contributed (Sorry Sergio) but I will do it in the next release.

I also want to finish the surprise feature that I have been planning for
release tomorrow, Metabase 2nd aniversary since its first public
release. I still need to verify that all works well to not rush
something not properly tested. Hang on.

Regards,
Manuel Lemos

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/driver_test.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase driver conformance test script with support for testing
result set bulk data fetching support.

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/driver_test.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>

Hello,

ok the driver tests run through on both my linux and my windows box
(aside from the lob test ... gah sorry ... still haven't had time to
check on a different machine ... we don't have any win98 boxes anymore
... but actually we have a couple win98 licenses so I could install it)

Function FetchResultArray($result,$row,&$array)
{
	 if(!mysql_data_seek($result,$row)
	 || GetType($array=mysql_fetch_row($result))!="array")
		 return($this->SetError("Fetch result
array",mysql_error($this->connection)));

$this->highest_fetched_row[$result]=max($this->highest_fetched_row[$resu
lt],$row);
	 return($this->ConvertResultRow($result,$array));
}

Is there a particular reason not to use is_array()?
Dunno when it was introduced exactly but it is listed as php3/php4 in
the manual and it looks cleaner imho (dunno about performance).

The mysql_data_seek is implemented to allow jumping to a specific row.
Do we need this flexibility (this is what I was talking about in my
previous email)? Or is this so you can better mix the various fetch
methods?

I see that you introduced a couple new functions instead of doing the
parameter approach with the query function. I am fine with that and it
even make the switch easier as this does not require any changes in the
drivers (and its always great to have as much logic as possible in the
metabase_database.php).

the format for Mysql Timestamps depends on the field length:
14:YYYYMMDDHHMMSS
12:YYMMDDHHMMSS
8:YYYYMMDD
6:YYMMDD

The ISO format you use in Metabase is the DATETIME type in Mysql.
I finally checked how you create a timestamp and you use DATETIME in
GetTimestampFieldTypeDeclaration. This is the source of my confusion and
why I keeped telling you that Timestamps need to be converted :-)
I thought you were using the Mysql Timestamp type.

We acutally make heavy use of Timestamps but I gather the way Mysql
handles it is non standard so we will have to get rid of all code that
relies on it.

Hmm, Mysql also seems to be lacking in time zone support.

Once Christopher gets to the office we have to finish up some stuff and
then we will write a couple test scenarios.

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Hi Manuel,

Work is exploding overhere and I will not have time to look at metabase
anymroe before Sunday evening .. maybe even Monday.
I did not see anything that bugged me (aside from the comments I mailed
earlier .. and that did not include any biggies)

Best regards,
Lukas Smith
smith@...
_______________________________
 DybNet Internet Solutions GbR
 Alt Moabit 89
 10559 Berlin
 Germany
 Tel. : +49 30 83 22 50 00
 Fax : +49 30 83 22 50 07
 www.dybnet.de info@...
_______________________________

Hello,

Lukas Smith wrote:
>
> Hello,
>
> ok the driver tests run through on both my linux and my windows box
> (aside from the lob test ... gah sorry ... still haven't had time to
> check on a different machine ... we don't have any win98 boxes anymore
> ... but actually we have a couple win98 licenses so I could install it)

Yes, I still need to support and test bulk fecthing LOB records that I
forgot.

There is a new MySQL-Max version. Please try that version in your
Windows platform now because I suspect that the malfunction was indeed a
MySQL bug.



> Function FetchResultArray($result,$row,&$array)
> {
>         if(!mysql_data_seek($result,$row)
>         || GetType($array=mysql_fetch_row($result))!="array")
>                 return($this->SetError("Fetch result
> array",mysql_error($this->connection)));
>
> $this->highest_fetched_row[$result]=max($this->highest_fetched_row[$resu
> lt],$row);
>         return($this->ConvertResultRow($result,$array));
> }
>
> Is there a particular reason not to use is_array()?
> Dunno when it was introduced exactly but it is listed as php3/php4 in
> the manual and it looks cleaner imho (dunno about performance).

Yes, it was introduced after PHP 3. Anyway, I can optimize this with
just a boolean verification because arrays evaluate true.



> The mysql_data_seek is implemented to allow jumping to a specific row.
> Do we need this flexibility (this is what I was talking about in my
> previous email)? Or is this so you can better mix the various fetch
> methods?

That is needed for random access for FetchResultArray, but I can
optimize this duplicating code inside FetchResultRow and FetchResultAll
without mysql_data_seek. I am just not sure if duplicating the code is
worthy not using mysql_data_seek.



> I see that you introduced a couple new functions instead of doing the
> parameter approach with the query function. I am fine with that and it
> even make the switch easier as this does not require any changes in the
> drivers (and its always great to have as much logic as possible in the
> metabase_database.php).

Exactly. :-)



> the format for Mysql Timestamps depends on the field length:
> 14:YYYYMMDDHHMMSS
> 12:YYMMDDHHMMSS
> 8:YYYYMMDD
> 6:YYMMDD
>
> The ISO format you use in Metabase is the DATETIME type in Mysql.
> I finally checked how you create a timestamp and you use DATETIME in
> GetTimestampFieldTypeDeclaration. This is the source of my confusion and
> why I keeped telling you that Timestamps need to be converted :-)
> I thought you were using the Mysql Timestamp type.
>
> We acutally make heavy use of Timestamps but I gather the way Mysql
> handles it is non standard so we will have to get rid of all code that
> relies on it.

Yes, using only the ISO format eliminates the porting problems between
databases.

Actually, I suppose the other formats do not save you space in the
database because they are stored as integers, not as text.

ALTER TABLE can make your format switch in the database without worries.
In your application it may be just a matter of moving the substr
offsets.


> Hmm, Mysql also seems to be lacking in time zone support.

Most other databases also do not put that in the database fields.
Applications that rely on time zones, should be converting values to GMT
before storing, and store the time zone information else where. It is
the same with storing subsecond timestamps. Or else portability will be
an headache.


> Once Christopher gets to the office we have to finish up some stuff and
> then we will write a couple test scenarios.

Great! :-)

Regards,
Manuel Lemos

Hello,

Lukas Smith wrote:
>
> Hi Manuel,
>
> Work is exploding overhere and I will not have time to look at metabase
> anymroe before Sunday evening .. maybe even Monday.
> I did not see anything that bugged me (aside from the comments I mailed
> earlier .. and that did not include any biggies)

Ok, don't worry. I think that if there are any remaining issues, those
should be mostly on optimization. If we don't optimize individual
drivers now, we can do it later without any need to change the current
API.

Take care,
Manuel Lemos

> Yes, I still need to support and test bulk fecthing LOB records that I
> forgot.
>
> There is a new MySQL-Max version. Please try that version in your
> Windows platform now because I suspect that the malfunction was indeed
a
> MySQL bug.

I downloaded and tested in a hurry ... still get the same error.
I will need to installe apache/php/mysql on one of the other boxes
(maybe even win98) to see if I can get it to work somehow

> ALTER TABLE can make your format switch in the database without
worries.
> In your application it may be just a matter of moving the substr
> offsets.

Unfortunately we relied on this autoupdate feature of the first
timestamp field on update ... but I guess its cleaner without it
anyways.

Best regards,
Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Hello,

Lukas Smith wrote:
>
> > Yes, I still need to support and test bulk fecthing LOB records that I
> > forgot.
> >
> > There is a new MySQL-Max version. Please try that version in your
> > Windows platform now because I suspect that the malfunction was indeed
> a
> > MySQL bug.
>
> I downloaded and tested in a hurry ... still get the same error.
> I will need to installe apache/php/mysql on one of the other boxes
> (maybe even win98) to see if I can get it to work somehow

You tried MySQL-Max 3.23.47 or just the new Metabase version?



> > ALTER TABLE can make your format switch in the database without
> worries.
> > In your application it may be just a matter of moving the substr
> > offsets.
>
> Unfortunately we relied on this autoupdate feature of the first
> timestamp field on update ... but I guess its cleaner without it
> anyways.
>

Use MetabaseNow() then.

Regards,
Manuel Lemos

> You tried MySQL-Max 3.23.47 or just the new Metabase version?

New Metabase with new MySQL (with a fresh install but I keeped the mysql
table so that I did not have to grant user rights)

Lukas Smith
smith@...
_______________________________
  DybNet Internet Solutions GbR
  Alt Moabit 89
  10559 Berlin
  Germany
  Tel. : +49 30 83 22 50 00
  Fax : +49 30 83 22 50 07
  www.dybnet.de info@...
_______________________________

Hello,

Lukas Smith wrote:
>
> > You tried MySQL-Max 3.23.47 or just the new Metabase version?
>
> New Metabase with new MySQL (with a fresh install but I keeped the mysql
> table so that I did not have to grant user rights)

Could that be a reason for failure? Can you please try it with newly
installed database by the new Metabase files when you have some time
free?

Regards,
Manuel Lemos

Hello All,

I am a newbie to world of Metabase and I am having a bit of trouble
hooking up the metabase library to a ODBC database that is on my
windows machine.  It is an Access file that is a system DSN.  I have
been able to connect to it with direct PHP calls:
____________
    //connect to database
    $connectionstring = odbc_connect("stockDB", "", "");

    //SQL query
    $Query = "SELECT stockID, stockSymbol, stockName FROM stockList
ORDER BY stockSymbol";

    //execute query
    $queryexe = odbc_do($connectionstring, $Query);
_____________
etc


Now I have trying to make this application to be a little more
database independent using metabase (Thank you Manual)

I have installed the package and got the driver_test.php to work as
well as it can (I think) with the ODBC type.  I am now trying to
perform the bare-bone hook-up and read stuff from an already made DB.

Here is my first stab that doesn't work:
__________________________________
require("metabase_configure.php"); //sets METABASE_PATH

require(METABASE_PATH."metabase_interface.php");
require(METABASE_PATH."metabase_database.php");

$database_array = array(
	 "Type"=>"odbc",
	 "IncludePath"=>METABASE_PATH ,
	 "options"=>array(
				 "DBADSN"=>"stockDB",
				 "DBAUser"=>"",
				 "DBAPassword"=>"",
				 "UseDefaultValues"=>0,
				 "UseDecimalScale"=>0,
				 "UseTransactions"=>0)
	 );

$error=MetabaseSetupDatabase($database_array,$database);


if($error!="")
{
	 echo "Database setup error: $error\n";
	 exit;
}

?>
__________________________


That's it and I seem to get the error:

Database setup error: Could not connect to ODBC server: IM002
[Microsoft][ODBC Driver Manager] Data source name not found and no
default driver specified


I think this has something to with not setting the name properly.  I
have looked for more examples but without much success.  Any help
would be appreciated.

-David

Guide to looking quite foolish in a new group immediately

1. Post Problem
2. Figure out that problem was caused by not capitalizing the
word "Options" in the original source code, thirty seconds after you
have posted a message.


Sorry to waste your time.  I'll post the detail of the app when I
finish it.

Thanks,
David

wndmlr wrote:
> Here is my first stab that doesn't work:
> __________________________________
> require("metabase_configure.php"); //sets METABASE_PATH
>
> require(METABASE_PATH."metabase_interface.php");
> require(METABASE_PATH."metabase_database.php");
>
> $database_array = array(
>         "Type"=>"odbc",
>         "IncludePath"=>METABASE_PATH ,
>         "options"=>array(
>                                 "DBADSN"=>"stockDB",
>                                 "DBAUser"=>"",
>                                 "DBAPassword"=>"",
>                                 "UseDefaultValues"=>0,
>                                 "UseDecimalScale"=>0,
>                                 "UseTransactions"=>0)
>         );
>
> $error=MetabaseSetupDatabase($database_array,$database);
>
> if($error!="")
> {
>         echo "Database setup error: $error\n";
>         exit;
> }
>
> ?>
> __________________________
>
> That's it and I seem to get the error:
>
> Database setup error: Could not connect to ODBC server: IM002
> [Microsoft][ODBC Driver Manager] Data source name not found and no
> default driver specified
>
> I think this has something to with not setting the name properly.  I
> have looked for more examples but without much success.  Any help
> would be appreciated.

What you did above, so far seems correct. MetabaseSetupDatabase does not
establish connections immediatly. Connections are established on demand
usually on the first query. What you seem to be missing is to specify to
which database you want to connect. ODBC does not have the concept of
connecting databases. It rather uses the concept of DSN to establish the
data source you want to connect to. In your case, before you execute any
queries you need to do something like:

MetabaseSetDatabase($database,"stockDB");

Setting the DBADSN as above is only meant for creating databases which
most ODBC data sources like Access don't support, so it will not be
possible to have Metabase to create a database for you. You need to use
one already created and use its DSN to specify as database name with the
above call.

Regards,
Manuel Lemos

Hello,

wndmlr wrote:
>
> Guide to looking quite foolish in a new group immediately
>
> 1. Post Problem
> 2. Figure out that problem was caused by not capitalizing the
> word "Options" in the original source code, thirty seconds after you
> have posted a message.
>
> Sorry to waste your time.  I'll post the detail of the app when I
> finish it.

Oh, I did not notice that as well. Anyway, as I mentioned before setting
DSN like is just meant for creating databases. For your regular scripts
you need to use MetabaseSetDatabase() to set the application DSN.

Regards,
Manuel Lemos

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the metabase-dev
group.

   File        : /beta/driver_test.php
   Uploaded by : mallemos <mlemos@...>
   Description : Metabase driver conformance test script with support for testing
SQL REPLACE queries and result set bulk data fetching support.

You can access this file at the URL

http://groups.yahoo.com/group/metabase-dev/files/beta/driver_test.php

To learn more about file sharing for your group, please visit

http://help.yahoo.com/help/us/groups/files

Regards,

mallemos <mlemos@...>