firebird-test — Firebird engine testing, test flight/suite discussion/information

Re: [Firebird-test] EVENT_MISC (Solaris x 86)

[Mark O'D. <mar...@lu...>]

Hi Konstantin

Konstantin Kuznetsov wrote:

> Hi All !
> 
> Now I am testing my Intel Solaris port
> With Classic FB all right. All tests passed.
> But in Super test event_misc sleeped and sql_events13 looped.
> Whats is on anover platforms with this tests?
> 
This test does seems to intermitantly cause problems on linux, I wanted 
to go back and revisit the discussion on it that happened previously 
since it may be the test that is wrong, or there is some subtle timing 
bug that is yet to worked out.

As with you it only happens with superserver, but for me it only 
happened twice in my 0.9-3 builds.  But.... when I ran it againg on the 
current build (in a slightly different mandrake 72 environment) I have 
had it happen again. 

Im moving back into testing again so I'll see if I get it again.

Cheers

Mark

[Firebird-test] EVENT_MISC (Solaris x 86)

[Konstantin K. <klk...@ns...>]

Hi All !

Now I am testing my Intel Solaris port
With Classic FB all right. All tests passed.
But in Super test event_misc sleeped and sql_events13 looped.
Whats is on anover platforms with this tests?


--
Konstantin Kuznetsov, phD

[Firebird-test] Getting TCS to work on remote db

[Mark O'D. <mar...@lu...>]

Hi Frank

Have you had any luck using TCS on remote databases.  I expect it's part 
of the Borland changes but superserver is a lot more restrictive about 
who can use it, and currently I cannot access a local databse from the 
isql client, except via localhost:xxxx.

Im not sure if this is a feature, or a bug, without giving it much 
though I thought it would though a local access would have connected to 
localhost:xxx by default.

Anyway the man thing is because of this the tcs database and all created 
databses need to use a remote connection.

I got something that sort of works, (I changed some of the hardcoded 
paths in drop_gds for instance) and set up the database template as 
locahost:xxxx but I had to have IB_USER and IB_PASSWORD defined and a 
few of the tests choked becuase they couldn't do something remotely. 

Have you tried running tcs in this sort of mode?

Cheers

Mark

-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] Change in working out where isc4.gdb is located?

[Mark O'D. <mar...@lu...>]

Hi Frank (and whoever)

When I start up the TCS test suite, and it adds all the test users, gsec 
seems to have trouble finding isc4.gdb unless my current directory is 
/opt/interbase.

Is there anything I should be doing, perhaps, exporting $INTERBASE env var.?

It used to work, but that was another machine, another version of linux 
(Im now on mandrake, was redhat).



PS: I like the idea of splitting the tests out into individual scripts.


Cheers

Mark

-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] Change in working out where isc4.gdb is located?

[Mark O'D. <mar...@lu...>]

Hi Frank (and whoever)

When I start up the TCS test suite, and it adds all the test users, gsec 
seems to have trouble finding isc4.gdb unless my current directory is 
/opt/interbase.

Is there anything I should be doing, perhaps, exporting $INTERBASE env var.?

It used to work, but that was another machine, another version of linux 
(Im now on mandrake, was redhat).



PS: I like the idea of splitting the tests out into individual scripts.


Cheers

Mark

-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] Test

[Mark O'D. <mar...@lu...>]

Test

[Firebird-test] Test - Ignore

[Mark O'D. <mar...@lu...>]

Test - where am I going

-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] New Version string of 0.9.4.XX : Was drop_gds side effect

[Mark O'D. <mar...@lu...>]

Hi All

With the 0.9-4 release the version string returned is:

T0.9.4.XX Firebird Test1

(I forget what we're up to with the XX, but it's a number).

Pat has found the first instance of parsing the version string in a 
utility in the TCS suite.

The main issue is that tools that parse out the major version number 
will get a 0, version 0 in the scheme of interbase things, wasn't very 
impressive and some tools may be looking for version > 4 or > 6.

So since this is the first version with the new string, it's worth 
keeping an eye of for problems using other tools that interact with 
Firebird.

If we strike too many incompatibilities, we'll go back and find another 
way round - probably by making the first firebird release in the 6.X range.


Cheers

Mark


Patrick J. P. Griffin wrote:

> Mark;
> 
> Sure,
> 
> In tcs/gds_drop/drop.c

And there I was searching though interbase/*/* ;-).

Yep it's a bonefide parse the version string command (in drop.c).  
get_version() with

#define VERSION_STRING "version \"%[A-Z]-%c%c.%c"
#define VERSION_MAJOR 1
#define VERSION_MINOR 2

     /* extract the vital version info from the string */
     if (sscanf(ptr, VERSION_STRING, machine,
                &ch[0], &ch[VERSION_MAJOR], &ch[VERSION_MINOR]))
        version = (ch[VERSION_MAJOR] - '0') * 10 + (ch[VERSION_MINOR] - 
'0');


Then if version < 40 then do some rsh stuff to delete the database.   
The rsh stuff looks like it would never be relevant to us anyway, so I'd 
say feel free to commit your change making this the only route used.

I think we did a quick check of tcs for dependancies on version a while 
ago but I guess this one hidden in it's own directory rather than the 
main tcs one was missed. 

I still think it's worth pushing through if we can, to aviod confusion 
with Borland releases, but Im willing to rollback if we get too many of 
these problems.

I'll cc this to firebird-devel about this, so that people can keep an 
eye out for this sort of thing (Reed gets first dibs on saying I told 
you so for this ;-).

Cheers

Mark

> First:
> 
>     /* extract the version into global variables */
>     version = 0;
>     isc_version(&db_handle, get_version, 0);
> 
> 
> Then:
> 
>     /* if the version is 4.0 then try isc_drop_database */
>     if (version >= 40)
>       {
> 
> 
> ...pat
> 
>  -----Original Message-----
> From: 	fir...@li...
> [mailto:fir...@li...]  On Behalf Of Mark
> O'Donohue
> Sent:	Tuesday, January 02, 2001 12:48 AM
> To:	fir...@li...
> Subject:	Re: [Firebird-test] drop_gds side effect
> 
> 
> Hi Pat
> 
> Could you give me a clue (like a file and function name ;-).
> 
> I've greped for gds_drop and had a brief look but there is nothing
> specific that I can try down to what your saying here.  But what you are
> saying here sounds like you are looking at a specific line of code.
> 
> Im interested, because if I have missed this comparison, there may be
> others.
> 
> At the time I checked fairly extensively for usage of IB_MAJOR_VER,
> IB_MINOR_VER and GDS_VERSION.
> 
> Cheers
> 
> Mark
> 
> Patrick J. P. Griffin wrote:
> 
> 
>> Mark, I believe this is result of changing the Major version from 6 to 0.
>> drop_gds is checking the Major and Minor Version ID before selecting
>> routines.
>> 
>> ...pat
>> 
>>  -----Original Message-----
>> From: 	fir...@li...
>> [mailto:fir...@li...]  On Behalf Of Mark
>> O'Donohue
>> Sent:	Monday, January 01, 2001 10:46 PM
>> To:	fir...@li...
>> Subject:	Re: [Firebird-test] drop_gds side effect
>> 
>> 
>> Hi Pat
>> 
>> Thanks for that, I'll try and verify it.  I presume your aware that the
>> changes are related to a security issue, and that some of the cvs
>> history has now been wiped (local copy kept of course).
>> 
>> Cheers
>> 
>> Mark
>> 
>> 
>> Patrick J. P. Griffin wrote:
>> 
>> 
>> 
>>> F.Y.I. I've noticed that the latest Firebird build (in my case
>> 
>> PA-T0.9.4.43
>> 
>> 
>>> Firebird Test1) has an unpleasant side-effect on drop_gds when attempting
>> 
>> to
>> 
>> 
>>> drop a database on a remote system.  This problem did not exist in build
>>> PA-T6.0.9.32.
>>> 
>>> Drop_gds is using the isc_version call and selects different routines
>> 
> when
> 
>>> running with versions greater than 4.0.
>>> 
>>> I'm sorry I'm not able to look at this problem closer at the moment.
>>> 
>>> ...pat
>>> p.s. Since I have no interest in versions of IB less than 4.0 I simply
>>> hacked on my copy gds_drop.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Firebird-test mailing list
>>> Fir...@li...
>>> http://lists.sourceforge.net/mailman/listinfo/firebird-test
>> 
>> 
>> --
>> Your database needs YOU!
>> http://firebird.sourceforge.net
>> 
>> 
>> _______________________________________________
>> Firebird-test mailing list
>> Fir...@li...
>> http://lists.sourceforge.net/mailman/listinfo/firebird-test
>> 
>> 
>> _______________________________________________
>> Firebird-test mailing list
>> Fir...@li...
>> http://lists.sourceforge.net/mailman/listinfo/firebird-test
> 
> 
> 
> --
> Your database needs YOU!
> http://firebird.sourceforge.net
> 
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test
> 
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test



-- 
Your database needs YOU!
http://firebird.sourceforge.net

RE: [Firebird-test] drop_gds side effect

[Patrick J. P. G. <Pat...@wo...>]

Mark;

Sure,

In tcs/gds_drop/drop.c

First:

    /* extract the version into global variables */
    version = 0;
    isc_version(&db_handle, get_version, 0);


Then:

    /* if the version is 4.0 then try isc_drop_database */
    if (version >= 40)
      {


...pat

 -----Original Message-----
From: 	fir...@li...
[mailto:fir...@li...]  On Behalf Of Mark
O'Donohue
Sent:	Tuesday, January 02, 2001 12:48 AM
To:	fir...@li...
Subject:	Re: [Firebird-test] drop_gds side effect


Hi Pat

Could you give me a clue (like a file and function name ;-).

I've greped for gds_drop and had a brief look but there is nothing
specific that I can try down to what your saying here.  But what you are
saying here sounds like you are looking at a specific line of code.

Im interested, because if I have missed this comparison, there may be
others.

At the time I checked fairly extensively for usage of IB_MAJOR_VER,
IB_MINOR_VER and GDS_VERSION.

Cheers

Mark

Patrick J. P. Griffin wrote:

> Mark, I believe this is result of changing the Major version from 6 to 0.
> drop_gds is checking the Major and Minor Version ID before selecting
> routines.
>
> ...pat
>
>  -----Original Message-----
> From: 	fir...@li...
> [mailto:fir...@li...]  On Behalf Of Mark
> O'Donohue
> Sent:	Monday, January 01, 2001 10:46 PM
> To:	fir...@li...
> Subject:	Re: [Firebird-test] drop_gds side effect
>
>
> Hi Pat
>
> Thanks for that, I'll try and verify it.  I presume your aware that the
> changes are related to a security issue, and that some of the cvs
> history has now been wiped (local copy kept of course).
>
> Cheers
>
> Mark
>
>
> Patrick J. P. Griffin wrote:
>
>
>> F.Y.I. I've noticed that the latest Firebird build (in my case
>
> PA-T0.9.4.43
>
>> Firebird Test1) has an unpleasant side-effect on drop_gds when attempting
>
> to
>
>> drop a database on a remote system.  This problem did not exist in build
>> PA-T6.0.9.32.
>>
>> Drop_gds is using the isc_version call and selects different routines
when
>> running with versions greater than 4.0.
>>
>> I'm sorry I'm not able to look at this problem closer at the moment.
>>
>> ...pat
>> p.s. Since I have no interest in versions of IB less than 4.0 I simply
>> hacked on my copy gds_drop.
>>
>>
>>
>> _______________________________________________
>> Firebird-test mailing list
>> Fir...@li...
>> http://lists.sourceforge.net/mailman/listinfo/firebird-test
>
>
>
> --
> Your database needs YOU!
> http://firebird.sourceforge.net
>
>
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test
>
>
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test



--
Your database needs YOU!
http://firebird.sourceforge.net


_______________________________________________
Firebird-test mailing list
Fir...@li...
http://lists.sourceforge.net/mailman/listinfo/firebird-test

Re: [Firebird-test] drop_gds side effect

[Mark O'D. <mar...@lu...>]

Hi Pat

Could you give me a clue (like a file and function name ;-).

I've greped for gds_drop and had a brief look but there is nothing 
specific that I can try down to what your saying here.  But what you are 
saying here sounds like you are looking at a specific line of code.

Im interested, because if I have missed this comparison, there may be 
others. 

At the time I checked fairly extensively for usage of IB_MAJOR_VER, 
IB_MINOR_VER and GDS_VERSION.

Cheers

Mark

Patrick J. P. Griffin wrote:

> Mark, I believe this is result of changing the Major version from 6 to 0.
> drop_gds is checking the Major and Minor Version ID before selecting
> routines.
> 
> ...pat
> 
>  -----Original Message-----
> From: 	fir...@li...
> [mailto:fir...@li...]  On Behalf Of Mark
> O'Donohue
> Sent:	Monday, January 01, 2001 10:46 PM
> To:	fir...@li...
> Subject:	Re: [Firebird-test] drop_gds side effect
> 
> 
> Hi Pat
> 
> Thanks for that, I'll try and verify it.  I presume your aware that the
> changes are related to a security issue, and that some of the cvs
> history has now been wiped (local copy kept of course).
> 
> Cheers
> 
> Mark
> 
> 
> Patrick J. P. Griffin wrote:
> 
> 
>> F.Y.I. I've noticed that the latest Firebird build (in my case
> 
> PA-T0.9.4.43
> 
>> Firebird Test1) has an unpleasant side-effect on drop_gds when attempting
> 
> to
> 
>> drop a database on a remote system.  This problem did not exist in build
>> PA-T6.0.9.32.
>> 
>> Drop_gds is using the isc_version call and selects different routines when
>> running with versions greater than 4.0.
>> 
>> I'm sorry I'm not able to look at this problem closer at the moment.
>> 
>> ...pat
>> p.s. Since I have no interest in versions of IB less than 4.0 I simply
>> hacked on my copy gds_drop.
>> 
>> 
>> 
>> _______________________________________________
>> Firebird-test mailing list
>> Fir...@li...
>> http://lists.sourceforge.net/mailman/listinfo/firebird-test
> 
> 
> 
> --
> Your database needs YOU!
> http://firebird.sourceforge.net
> 
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test
> 
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test



-- 
Your database needs YOU!
http://firebird.sourceforge.net

RE: [Firebird-test] drop_gds side effect

[Patrick J. P. G. <Pat...@wo...>]

Mark, I believe this is result of changing the Major version from 6 to 0.
drop_gds is checking the Major and Minor Version ID before selecting
routines.

...pat

 -----Original Message-----
From: 	fir...@li...
[mailto:fir...@li...]  On Behalf Of Mark
O'Donohue
Sent:	Monday, January 01, 2001 10:46 PM
To:	fir...@li...
Subject:	Re: [Firebird-test] drop_gds side effect


Hi Pat

Thanks for that, I'll try and verify it.  I presume your aware that the
changes are related to a security issue, and that some of the cvs
history has now been wiped (local copy kept of course).

Cheers

Mark


Patrick J. P. Griffin wrote:

> F.Y.I. I've noticed that the latest Firebird build (in my case
PA-T0.9.4.43
> Firebird Test1) has an unpleasant side-effect on drop_gds when attempting
to
> drop a database on a remote system.  This problem did not exist in build
> PA-T6.0.9.32.
>
> Drop_gds is using the isc_version call and selects different routines when
> running with versions greater than 4.0.
>
> I'm sorry I'm not able to look at this problem closer at the moment.
>
> ...pat
> p.s. Since I have no interest in versions of IB less than 4.0 I simply
> hacked on my copy gds_drop.
>
>
>
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test



--
Your database needs YOU!
http://firebird.sourceforge.net


_______________________________________________
Firebird-test mailing list
Fir...@li...
http://lists.sourceforge.net/mailman/listinfo/firebird-test

Re: [Firebird-test] drop_gds side effect

[Mark O'D. <mar...@lu...>]

Hi Pat

Thanks for that, I'll try and verify it.  I presume your aware that the 
changes are related to a security issue, and that some of the cvs 
history has now been wiped (local copy kept of course).

Cheers

Mark


Patrick J. P. Griffin wrote:

> F.Y.I. I've noticed that the latest Firebird build (in my case PA-T0.9.4.43
> Firebird Test1) has an unpleasant side-effect on drop_gds when attempting to
> drop a database on a remote system.  This problem did not exist in build
> PA-T6.0.9.32.
> 
> Drop_gds is using the isc_version call and selects different routines when
> running with versions greater than 4.0.
> 
> I'm sorry I'm not able to look at this problem closer at the moment.
> 
> ...pat
> p.s. Since I have no interest in versions of IB less than 4.0 I simply
> hacked on my copy gds_drop.
> 
> 
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> http://lists.sourceforge.net/mailman/listinfo/firebird-test



-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] drop_gds side effect

[Patrick J. P. G. <Pat...@wo...>]

F.Y.I. I've noticed that the latest Firebird build (in my case PA-T0.9.4.43
Firebird Test1) has an unpleasant side-effect on drop_gds when attempting to
drop a database on a remote system.  This problem did not exist in build
PA-T6.0.9.32.

Drop_gds is using the isc_version call and selects different routines when
running with versions greater than 4.0.

I'm sorry I'm not able to look at this problem closer at the moment.

...pat
p.s. Since I have no interest in versions of IB less than 4.0 I simply
hacked on my copy gds_drop.

Re: [Firebird-test] Test for auto increment feature

[Mark O'D. <mar...@lu...>]

Hi Frank.

Done it - and it works fine.

One comment though I see you've got $log$ in dummy.

I suspect it so you can folow whats going on, but usage of this 
particular RCS thing is absolutely dangerous when it comes to trying to 
merge variant branches of a CVS tree.

So its best avoided if possible .

Cheers

Mark


Sch...@t-... wrote:

> Hi all,
> I have added an autoincremented file named this_build to the TCS 
> module, and surprisingly it is working for me.
> 
> To test this a bit more I would like some of you to do the following:
> 
> check out TCS/this_build and TCS/dummy
> change 'dummy' as you like
> take a look at the number in 'this_build'
> commit dummy with sth. like
> cvs -t -z4 commit -m "test for auto increment" TCS/dummy
> (this will show some trace messages that may be helpful if
>   something fails)
> check out TCS/this_build and check whether it was incremented.
> 
> cheers
> 
> Frank
> 



-- 
Your database needs YOU!
http://firebird.sourceforge.net

[Firebird-test] Test for auto increment feature

[<Sch...@t-...>]

Hi all,
I have added an autoincremented file named this_build to the TCS 
module, and surprisingly it is working for me.

To test this a bit more I would like some of you to do the following:

check out TCS/this_build and TCS/dummy
change 'dummy' as you like
take a look at the number in 'this_build'
commit dummy with sth. like
cvs -t -z4 commit -m "test for auto increment" TCS/dummy
(this will show some trace messages that may be helpful if
  something fails)
check out TCS/this_build and check whether it was incremented.

cheers

Frank

-- 
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."
         - J.K. Rowling
http://firebird.sourceforge.net

Re: [Firebird-test] Re: [Firebird-devel] New Version of TCS installation for Linux

[Neil M. <nm...@zi...>]

On Tue, Nov 14, 2000 at 07:37:41AM +0100, Frank Schlottmann-Goedde wrote:
> Neil McCalden schrieb:
> 
> > I have also installed the kit on Solaris using your gtcs.gdb
> > with a updated so_ltcs.gdb and the vector_12hour test passes on a
> > classic server. Two tests reported a failure with your updated
> > output but passed if the original results were used, which is also what
> > v4 produces with the same query.
> 
> Could you please tell me which tests failed, and if possible
> provide the diffs for that failure.
> 

Frank,

Sorry for the late reply.

The tests are c_isql_join_3 and c_isql_join4 the diff output from TCS is
below. While I am curious to find out if the order is architecture
dependent, I think solution is to add an order by clause to the queries
to ensure consistency.

 
Running global test C_SQL_JOIN_2         ... passed
Running global test C_SQL_JOIN_3         ... *** failed ****
Test C_SQL_JOIN_3         failed on 25-NOV-2000:
	initialized by FSG                  
	on 16-OCT-2000 with boilerplate QA_BP               
-------------------
5 a 5 
> Cubs                 Chicago               Illinois            
++++++++++++++++++++++++++++++++++++++++++++++++++
6 d 7
< Cubs                 Chicago               Illinois            
++++++++++++++++++++++++++++++++++++++++++++++++++
13 a 13 
> Mets                 New York              New York            
++++++++++++++++++++++++++++++++++++++++++++++++++
14 d 15
< Mets                 New York              New York            
++++++++++++++++++++++++++++++++++++++++++++++++++
29 a 29 
> Cubs            Chicago                   Illinois
++++++++++++++++++++++++++++++++++++++++++++++++++
30 d 31
< Cubs            Chicago                   Illinois
++++++++++++++++++++++++++++++++++++++++++++++++++
37 a 37 
> Mets            New York                  New York
++++++++++++++++++++++++++++++++++++++++++++++++++
38 d 39
< Mets            New York                  New York
++++++++++++++++++++++++++++++++++++++++++++++++++
47,48 c 47,48
< 
---------------------------------------------
> 
++++++++++++++++++++++++++++++++++++++++++++++++++
54 a 54 
> Cubs            Chicago                   Illinois                  
++++++++++++++++++++++++++++++++++++++++++++++++++
55 d 56
< Cubs            Chicago                   Illinois                  
++++++++++++++++++++++++++++++++++++++++++++++++++
62 a 62 
> Mets            New York                  New York                  
++++++++++++++++++++++++++++++++++++++++++++++++++
63 d 64
< Mets            New York                  New York                  
++++++++++++++++++++++++++++++++++++++++++++++++++

-------------------
Running global test C_SQL_JOIN_4         ... *** failed ****
Test C_SQL_JOIN_4         failed on 25-NOV-2000:
	initialized by FSG                  
	on 16-OCT-2000 with boilerplate QA_BP               
-------------------
5 a 5 
> Cubs                 Chicago               Illinois            
++++++++++++++++++++++++++++++++++++++++++++++++++
6 d 7
< Cubs                 Chicago               Illinois            
++++++++++++++++++++++++++++++++++++++++++++++++++
13 a 13 
> Mets                 New York              New York            
++++++++++++++++++++++++++++++++++++++++++++++++++
14 d 15
< Mets                 New York              New York            
++++++++++++++++++++++++++++++++++++++++++++++++++
29 a 29 
> Cubs            Chicago                   Illinois
++++++++++++++++++++++++++++++++++++++++++++++++++
30 d 31
< Cubs            Chicago                   Illinois
++++++++++++++++++++++++++++++++++++++++++++++++++
37 a 37 
> Mets            New York                  New York
++++++++++++++++++++++++++++++++++++++++++++++++++
38 d 39
< Mets            New York                  New York
++++++++++++++++++++++++++++++++++++++++++++++++++
47,48 c 47,48
< 
---------------------------------------------
> 
++++++++++++++++++++++++++++++++++++++++++++++++++
54 a 54 
> Cubs            Chicago                   Illinois                  
++++++++++++++++++++++++++++++++++++++++++++++++++
55 d 56
< Cubs            Chicago                   Illinois                  
++++++++++++++++++++++++++++++++++++++++++++++++++
62 a 62 
> Mets            New York                  New York                  
++++++++++++++++++++++++++++++++++++++++++++++++++
63 d 64
< Mets            New York                  New York                  
++++++++++++++++++++++++++++++++++++++++++++++++++

-------------------
Running global test C_SQL_JOIN_5         ... passed
Running global test C_SQL_JOIN_6         ... passed


-- 
Neil McCalden                @home     nm...@zi...     

Re: [Firebird-test] Re: [Firebird-devel] New Version of TCS installation for Linux

[<Sch...@t-...>]

Neil McCalden schrieb:

> I have also installed the kit on Solaris using your gtcs.gdb
> with a updated so_ltcs.gdb and the vector_12hour test passes on a
> classic server. Two tests reported a failure with your updated
> output but passed if the original results were used, which is also what
> v4 produces with the same query.

Could you please tell me which tests failed, and if possible
provide the diffs for that failure.

Frank

-- 
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird

[Firebird-test] Re: [Firebird-devel] New Version of TCS installation for Linux

[Neil M. <nm...@zi...>]

On Mon, Nov 13, 2000 at 08:20:19AM +0100, Frank Schlottmann-Goedde wrote:
> Hi,
> I have placed a new version of the installation routine
> for the test control system for linux at
> ftp://firebird.sourceforge.net/pub/firebird/TCS/TCS_linux.tar
> 
> This will use the new TCS version from the firebird tree
> (simplified the whole thing significantly:-)
> 
> BTW, has anyone tried this with a Net/FreeBSD version?

The last kit installed and ran all the tests ok on a classic server on
linux, once I found out tan was not required. 

I have also installed the kit on Solaris using your gtcs.gdb
with a updated so_ltcs.gdb and the vector_12hour test passes on a
classic server. Two tests reported a failure with your updated
output but passed if the original results were used, which is also what
v4 produces with the same query.
I will check out the latest version and give details if this still
happens.

-- 
Neil McCalden                @home     nm...@zi...     

[Firebird-test] New Version of TCS installation for Linux

[<Sch...@t-...>]

Hi,
I have placed a new version of the installation routine
for the test control system for linux at
ftp://firebird.sourceforge.net/pub/firebird/TCS/TCS_linux.tar

This will use the new TCS version from the firebird tree
(simplified the whole thing significantly:-)

BTW, has anyone tried this with a Net/FreeBSD version?

Frank
 
-- 
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird

Re: [Firebird-test] Re: patch run

[<Sch...@t-...>]

Mark O'Donohue schrieb:
> 
> Patrick J. P. Griffin wrote:
> 
> > Mark,
> >
> > Thanks, I've checked the output you've sent me and the results are exactly
> > what I hoped to see.
> 
> Thats pleasant.
> 
> > I'll admit that I've avoided uploading result sets because I had assumed
> > that the different database paths would cause them to be marked as failed.
> > I now see, even looking at my own result sets, that TCS must contain coding
> > to account for those differences without failing the test.
> >
> 
> I must admit my knowledge is limited to doing some simple runs, from the
> little bit I looked at it seemed partially up to the test itself to
> determine if it was successful.   I presume we'll all know how to do it
> pretty soon.

The compare routine in the tcs sorts out some things like
database names, paths and other "nuisances" . So the initializations 
can be shared for different setups (and I hope platforms).
After I have fixed this thing to work with blobs of any segment size 
I will surely know more :-)

Frank

-- 
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird

[Firebird-test] Re: patch run

[Mark O'D. <mar...@lu...>]

Patrick J. P. Griffin wrote:

> Mark,
> 
> Thanks, I've checked the output you've sent me and the results are exactly
> what I hoped to see.

Thats pleasant.

> I'll admit that I've avoided uploading result sets because I had assumed
> that the different database paths would cause them to be marked as failed.
> I now see, even looking at my own result sets, that TCS must contain coding
> to account for those differences without failing the test.
> 

I must admit my knowledge is limited to doing some simple runs, from the 
little bit I looked at it seemed partially up to the test itself to 
determine if it was successful.   I presume we'll all know how to do it 
pretty soon.

Cheers

Mark

Re: [Firebird-test] New module TCS

[Mark O'D. <mar...@lu...>]

Sch...@t-... wrote:

> I'm considering to add a new module named TCS to the cvs tree.
> This would include initially the original TCS files from inprise,
> so that the changes that I intend would be logged.
> 
> From some tests it seems that cvs is quite capable of handling 
> gbk-files, so we could place actual copies of the test databases here.
> (will need another look at syncmail though)

Sounds good to me, I thought we would get to this point at sometime.  
Perhaps we should change syncmail to just ignore TCS.  The test suite 
isn't really what people are touchy about reviewing the changes.

> I would like to see Pat's test database here, seems to be the
> most complete at the moment. ( I have lost my bugs series due
> to a combination of ex- and imports with an failing nightly 
> backup due to a startup error :-(

Sounds good,

> Frank
> 
> 



-- 
Your database needs YOU!
http://sourceforge.net/projects/firebird

[Firebird-test] New module TCS

[<Sch...@t-...>]

I'm considering to add a new module named TCS to the cvs tree.
This would include initially the original TCS files from inprise,
so that the changes that I intend would be logged.

From some tests it seems that cvs is quite capable of handling 
gbk-files, so we could place actual copies of the test databases here.
(will need another look at syncmail though)

I would like to see Pat's test database here, seems to be the
most complete at the moment. ( I have lost my bugs series due
to a combination of ex- and imports with an failing nightly 
backup due to a startup error :-(

Frank


-- 
"Fascinating creatures, phoenixes. They can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird

[Firebird-test] syncmail reenabled

[<Sch...@t-...>]

Hi,
I have reenabled syncmail and changed it
to mail only the names of added files instead of the
contents.

Frank

-- 
"Fascinating creature, phoenixes, they can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird

Re: [Firebird-test] Blob segmentation in gtcs.gdb

[<Sch...@t-...>]

Mark O'Donohue schrieb:
> 
> Hi Frank
> 
> If we need to we can store ib-tests in our CVS tree just in a different
> module so it's not part of the interbase download.  Ultimately it's not a
> bad idea to have our own copy, and it's pretty easy to do.
> 
> So if you eventually decide you need to make a change, I think we'll put
> import it into our CVS tree.
> 

I had hoped that I could avoid this, but at the moment it seems
to me that I have to make some significant changes to the 
TCS code to get it to work as I would like it. So I will create
a new module as soon as I have something working. 

What about a module test (or ib_test or fb_test), which would contain 
the TCS source tree and a test pool?

Frank

-- 
"Fascinating creature, phoenixes, they can carry immensely heavy loads,
 their tears have healing powers and they make highly faithful pets."  
         - J.K. Rowling

http://sourceforge.net/projects/firebird