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

[Firebird-test] Hey 2507Mhja9-749pU-14

[<Mil...@ho...>]

PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1t
YWlsIC0tPg0KPEhUTUw+PEhFQUQ+DQo8VElUTEU+SW5zdGEtQnJ1c2ggRGlz
cG9zYWJsZSBUb290aGJydXNoZXM8L1RJVExFPg0KPFNUWUxFPkE6bGluayB7
Y29sb3I6cmVkfTwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm
ZmZmZmY+DQo8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0xNCB3
aWR0aD02MDAgYm9yZGVyPTMgYm9yZGVyY29sb3JkYXJrPSMwMDMzNjYgYm9y
ZGVyY29sb3JsaWdodD0jNjY5OTk5IGJvcmRlcmNvbG9yPSMwMDMzNjY+DQog
IDxUQk9EWT4NCgk8VFI+DQoJPFREIHdpZHRoPTIwMCBiZ2NvbG9yPSM0Njgy
YjQgdmFsaWduPXRvcD48Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlhbCIgY29s
b3I9I2ZmZmZmZiBzaXplPTQ+DQoJCTxCPkRPTidUIERSRUFNIFRPIExJVkUh
IC4uLjxCUj48QlI+TElWRSBUSEUgRFJFQU08L0I+PEJSPjwvRk9OVD4NCgkJ
PEZPTlQgZmFjZT0iVmVyZGFuYSwgQXJpYWwiIGNvbG9yPSNmZmZmZmYgc2l6
ZT0yPjxCUj48Qj4NCgkJPExJPkJlIHlvdXIgb3duIEJPU1MNCgkJPExJPldv
cmsgeW91ciBvd24gSE9VUlMNCgkJPExJPk5vIEZJWEVEIG92ZXJoZWFkDQoJ
CTxMST5IaWdoIENBU0ggcmV0dXJuIA0KCQk8TEk+SU5DT01FIFN1cHBsZW1l
bnQNCgkJPExJPlBhcnQgVGltZSBCdXNpbmVzczwvQj48L0ZPTlQ+PC9MST4N
CgkJPGZvbnQgY29sb3I9IzQ2ODJiND5xd2VydHl1aW9wbGtqPEJSPmhnZmRz
YXp4Y3Zibm0sLjxCUj4vMDk4NzY1NDMyMTxCUj5rZGpkamRoZnloc2dnZjxC
Uj5KREhYR0ROR0RSVzxCUj5LRk9GR0pESERIR1M8QlI+c2F6eGN2Ym5tLC48
QlI+LzA5ODc2NTQzMjE8QlI+a2RqZGpkaGZ5aHNnZ2Y8QlI+SkRIWEdEPEJS
PnF3ZXJ0eXVpb3Bsa2o8QlI+aGdmZHNhenhjdmJubSwuPEJSPi8wOTg3NjU0
MzIxPEJSPmtkamRqZGhmeWhzZ2dmPEJSPkpESFhHRE5HRFJXPEJSPktGT0ZH
SkRIREhHUzwvZm9udD4NCgk8L1REPg0KICAgIDxURCAgd2lkdGg9NDAwPg0K
CQk8Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlhbCIgY29sb3I9IzAwMDA1MCBz
aXplPTM+DQoJCTxCPkRlYXIgRnV0dXJlIEJ1c2luZXNzIE93bmVyLDwvQj4g
DQoJCTxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlh
bCIgY29sb3I9IzAwMDA1MCBzaXplPTI+DQoJCVlvdSBjYW4gbm93IGZvciB0
aGUgZmlyc3QgdGltZSwgb3duIGEgYnVzaW5lc3MgaW4geW91ciBhcmVhIHdp
dGggdGhlIG1vc3QgdW5pcXVlLCBpbm5vdmF0aXZlIHByb2R1Y3QgaW4gQW1l
cmljYSB0b2RheS48QlI+PEJSPg0KCQlXb3JrIGxlc3MgdGhhbiB0ZW4gaG91
cnMgYSB3ZWVrIHdpdGggdGhlIHBvdGVudGlhbCB0byBlYXJuICQ1MCwwMDAg
YSB5ZWFyLjxCUj48QlI+SGVyZSdzIGhvdyEgIE92ZXIgMzAwIE1pbGxpb24g
cGVvcGxlIHVzZSB0aGlzIHByb2R1Y3QgaW4gdGhlIFUuUy4NCgkJZGFpbHks
IHRoYXQncyByaWdodCwgb3ZlciAzMDAgTWlsbGlvbiBwZW9wbGUuPEJSPjxm
b250IGNvbG9yPSNGRkZGRkY+cXdlcnR5dWlvcGxrampmamhtLC47cG9peXU1
U0hERkpJRkxoZ2Zkc2F6eGN2Ym5tLC48L2ZvbnQ+PEJSPlRoZSBwcm9maXQg
bWFyZ2luIHdpdGggdXMgaXMgYW4gYW1hemluZyA0MDAlLCB5b3Ugd2lsbCBi
ZSBzYXlpbmcNCgkJdG8geW91cnNlbGYgd2h5IGRpZG4ndCBJIHRoaW5rIG9m
IHRoYXQhPEJSPjxmb250IGNvbG9yPSNGRkZGRkY+cXdlcnR5dWlvcGxrampm
amhtLC47cG9peXU1U0hERkpJRkxoZ2Zkc2F6eGN2Ym5tLC48L2ZvbnQ+PEJS
PglCcmVhayBkb3duIHRoZSB3YWxscyBhbmQgbGl2ZSB0aGlzIGxpZmUgeW91
J3ZlIG9ubHkgZHJlYW1lZCBhYm91dC48QlI+PEJSPg0KCQlMZXNzIHRoZW4g
MTBLIHJlcXVpcmVkIHRvIGdldCBzdGFydGVkLjxCUj5BdmFpbGFiaWx0eSBp
cyB5b3VyIGFyZWEgaXMgbGltaXRlZC48QlI+PEEgaHJlZj0iaHR0cDovLzM2
NS5saWFuZ3NoYW5wby5jb20vYnJ1c2gvIj4NCgkJPEI+Q0xJQ0sgSEVSRSBO
T1c8L0I+PC9BPjxCUj5TbyB5b3UgdG9vIGNhbiByZWNlaXZlIHlvdXIgZnJl
ZSBpbmZvcm1hdGlvbiBwYWNrYWdlIHRvZGF5Lg0KCQk8QlI+PEJSPjxBIGhy
ZWY9Imh0dHA6Ly8zNjUubGlhbmdzaGFucG8uY29tL2JydXNoLyI+DQoJCTxG
T05UIGZhY2U9IlZlcmRhbmEsIEFyaWFsIiBjb2xvcj0jY2MzMzMzIHNpemU9
NT48Qj48ST5Eb24ndCB3YWl0IGFueSBsb25nZXIhPEJSPkdldCBTdGFydGVk
IFRvZGF5ISE8L0k+PC9CPjwvRk9OVD48L0E+PC9GT05UPjwvUD4NCgk8L1RE
PjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj4NCjxUQUJMRSB3aWR0aD01NTA+
DQogIDxUQk9EWT4NCiAgPFRSID4NCiAgICA8VEQgYWxpZ249Y2VudGVyPg0K
CQk8SFIgU0laRT0xIHdpZHRoPSIxMDAlIiBjb2xvcj1pbmRpZ28+DQoJCTxm
b250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsIj5Zb3VyIGVtYWls
IGFkZHJlc3Mgd2FzIG9idGFpbmVkIGZyb20gYW4gb3B0LWluIGxpc3QuIE9w
dC1pbiBNUlNBIExpc3QNCgkJPEJSPlB1cmNoYXNlIENvZGUgIyAzMTItMjQx
Mi4gIElmIHlvdSB3aXNoIHRvIGJlIHVuc3Vic2NyaWJlZCBmcm9tIHRoaXMg
bGlzdCwgcGxlYXNlIDxBIGhyZWY9Imh0dHA6Ly8zNjUubGlhbmdzaGFucG8u
Y29tL2JydXNoL3JlbW92ZS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+Y2xpY2sg
aGVyZTwvQT48L2ZvbnQ+DQoJCTxmb250IGNvbG9yPWZmZmZmZj5xd2VydHl1
aW9wbGtqaGdmZHNhenhjdmJubSwuLzA5ODc2NTQzMjE8L2ZvbnQ+DQogICAg
PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0JPRFk+PC9IVE1MPg0KMDls
Mg==

[Firebird-test] Limited Offer

[<Ana...@ho...>]

PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1t
YWlsIC0tPg0KPGh0bWw+PGhlYWQ+DQo8dGl0bGU+TmV3IEludmVzdG1lbnQg
UGFydG5lciBQcm9kdWN0IEFubm91bmNlbWVudDwvdGl0bGU+DQo8U1RZTEU+
QTpsaW5rIHtjb2xvcjojYjIyMjIyOyB0ZXh0LWRlY29yYXRpb246bm9uZX0N
ClAge3RleHQtYWxpZ246Y2VudGVyOyBmb250OiBib2xkIDE4cHQgIlZlcmRh
bmEiLCAiQXJpYWwifQ0KUC50eHQge3RleHQtYWxpZ246Y2VudGVyOyBmb250
OiBub3JtYWwgMTRwdCAiVmVyZGFuYSIsICJBcmlhbCI7IGxldHRlci1zcGFj
aW5nOi4xMGVtO30NClAuc3RyZXRjaCB7dGV4dC1hbGlnbjpjZW50ZXI7IGZv
bnQ6IGJvbGQgMjBwdCAiVmVyZGFuYSIsICJBcmlhbCI7IGxldHRlci1zcGFj
aW5nOjEuNWVtfQ0KUC5zbWxUeHQge3RleHQtYWxpZ246Y2VudGVyOyBmb250
OiBub3JtYWwgMTBwdCAiVmVyZGFuYSIsICJBcmlhbCI7fQ0KSDEge3RleHQt
YWxpZ246Y2VudGVyOyBmb250OiBib2xkIDI0cHQgIlZlcmRhbmEiLCAiQXJp
YWwiOyBjb2xvcj13aGl0ZX08L1NUWUxFPg0KPC9oZWFkPjxib2R5IGJnY29s
b3I9IiNmZmZmZmYiIHRleHQ9I2ZmZmZmZj48Y2VudGVyPg0KPHRhYmxlIHdp
ZHRoPSI1NTAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMiIgYm9y
ZGVyPSIzIiA+DQoNCjx0cj48dGQgYmdjb2xvcj0iIzAwMDAwMCI+DQo8dGFi
bGUgd2lkdGg9IjU1MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIw
IiBib3JkZXI9IjAiPg0KDQo8dHI+PHRkIGJnY29sb3I9IiMwMDAwMDAiPg0K
Jm5ic3A7PC90ZD4NCjwvdHI+DQoNCjx0cj48dGQgYmdjb2xvcj0iI2ZmZmZm
ZiIgdmFsaWduPSJ0b3AiPjx0YWJsZSB3aWR0aD0iNTUwIiBib3JkZXI9IjAi
IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iNCI+DQo8dHI+PHRkIHZh
bGlnbj1jZW50ZXIgYWxpZ249bWlkZGxlIGJnY29sb3I9IiNmZjk5MDAiIHdp
ZHRoPTU1Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5uZXd0b3BpY3MuY29tLzI1
MC1CaWxsaW9uLURvbGxhci1NYXJrZXRwbGFjZS8iPjxIMT48Qj5OPEJSPkU8
QlI+VzxCUj48QlI+RTxCUj5DPEJSPk88QlI+TjxCUj5PPEJSPk08QlI+WTwv
YT48L0I+PC9IMT48L3RkPg0KDQo8dGQgdmFsaWduPSJ0b3AiIGJnY29sb3I9
IiM2Njk5ZmYiPjx0YWJsZSB3aWR0aD00NTUgY2VsbHNwYWNpbmc9IjAiIGNl
bGxwYWRkaW5nPSIxNCIgYm9yZGVyPSIwIiBhbGlnbj1jZW50ZXIgc3R5bGU9
IldJRFRIOiA0NTVweCI+DQo8dHI+PHRkIGJnY29sb3I9IiM2Njk5ZmYiIGFs
aWduPW1pZGRsZSAgdmFsaWduPWNlbnRlcj48UD5FQVJOIFVQIFRPIDI0JSBB
Tk5VQUxMWTwvUD48UCBjbGFzcz10eHQ+Tm93IHlvdSBjYW4gaW52ZXN0IGlu
IHRoZSBtb3N0IG5lZWRlZCBhbmQgZmFzdGVkIGdyb3dpbmcgaW5kdXN0cnkg
aW4gdGhlIHdvcmxkPC9QPjxQIGNsYXNzPXN0cmV0Y2g+U0VDVVJJVFkhPC9Q
PjxQIGNsYXNzPXR4dD5HZXQgdGhlIGRldGFpbHMgb24gdGhpczxCUj48YSBo
cmVmPSJodHRwOi8vd3d3Lm5ld3RvcGljcy5jb20vMjUwLUJpbGxpb24tRG9s
bGFyLU1hcmtldHBsYWNlLyI+MjUwIEJpbGxpb24tRG9sbGFyIE1hcmtldHBs
YWNlPC9hPjxCUj48QlI+PEJSPlBBWVMgUVVBUlRFUkxZIENBU0ggRElTVFJJ
QlVUSU9OUzwvUD48YSBocmVmPSJodHRwOi8vd3d3Lm5ld3RvcGljcy5jb20v
MjUwLUJpbGxpb24tRG9sbGFyLU1hcmtldHBsYWNlLyI+PFA+Q0xJQ0sgSEVS
RSBGT1IgWU9VUiBGUkVFIElORk9STUFUSU9OPC9QPjwvYT48UCBjbGFzcz1z
bWxUeHQ+WU9VIE1VU1QgQkUgMjEgT1IgT0xERVIgVE8gUVVBTElGWTwvUD48
L3RkPg0KPC90cj48L3RhYmxlPjwvdGQ+DQoNCjwvdHI+PC90YWJsZT48L3Rk
Pg0KPC90cj4NCg0KPHRyPg0KPHRkIGJnY29sb3I9IiMwMDAwMDAiIGFsaWdu
PSJtaWRkbGUiIGNvbHNwYW49IjIiPg0KDQo8dGFibGUgYm9yZGVyPSIwIiBj
ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjIiIGFsaWduPWxlZnQ+DQo8
dHI+PHRkPjxIUiBTSVpFPTEgd2lkdGg9IjEwMCUiIGNvbG9yPXdoaXRlPjxm
b250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFyaWFsIj5Zb3VyIHByaXZh
Y3kgaXMgZXh0cmVtZWx5IGltcG9ydGFudCB0byB1cy4gJm5ic3A7WW91IHJl
cXVlc3RlZCB0byByZWNlaXZlIHRoaXMgbWFpbGluZywgYnkgc3Vic2NyaWJp
bmcgdGhyb3VnaCBvbmUgb2Ygb3VyIG1hcmtldGluZyBwYXJ0bmVycy4gJm5i
c3A7QXMgYSBsZWFkZXIgaW4gZW1haWwgbWFya2V0aW5nLCB3ZSBhcmUgY29t
bWl0dGVkIHRvIGRlbGl2ZXJpbmcgYSBoaWdobHkgcmV3YXJkaW5nIGV4cGVy
aWVuY2UsIHdpdGggb2ZmZXJzIHRoYXQgaW5jbHVkZSBiYXJnYWlucywgDQpl
bnRlcnRhaW5tZW50LCBhbmQgIG1vbmV5LW1ha2luZyBpZGVhcy4gJm5ic3A7
SG93ZXZlciwgaWYgeW91IHdpc2ggdG8gdW5zdWJzY3JpYmUsPEEgaHJlZj0i
aHR0cDovL3d3dy5uZXd0b3BpY3MuY29tL3Rha2VtZW9mZi8iIHRhcmdldD0i
X2JsYW5rIj4gY2xpY2sgaGVyZS48L0E+ICZuYnNwO1RoaXJkLXBhcnR5IG9m
ZmVycyBjb250YWluZWQgaW4gdGhpcyBlbWFpbCBhcmUgdGhlIHNvbGUgcmVz
cG9uc2liaWxpdHkgb2YgdGhlIG9mZmVyIG9yaWdpbmF0b3IuPC9mb250Pjwv
dGQ+DQo8L3RyPjwvdGFibGU+PC90ZD4NCg0KPC90cj48L3RhYmxlPjwvdGQ+
DQoNCjwvdHI+PC90YWJsZT48L2NlbnRlcj48L2JvZHk+PC9odG1sPg0KDQox
MjQ1aXhnYzAtNTU3Y2hVazk4MTNTVHhWNi0yMTZlQ2tmMDQzNndPSEs0LTYz
NGw0NA==

[Firebird-test] Investor information

[<Jac...@fr...>]

T24gSmFudWFyeSAxc3QgMjAwMiwgdGhlIEV1cm9wZWFuIGNvdW50cmllcyBi
ZWdhbg0KdXNpbmcgdGhlIG5ldyBFdXJvLiAgTmV2ZXIgYmVmb3JlIGhhdmUg
c28NCm1hbnkgY291bnRyaWVzIHdpdGggc3VjaCBwb3dlcmZ1bCBlY29ub21p
ZXMgdW5pdGVkDQp0byB1c2UgYSBzaW5nbGUgY3VycmVuY3kuICBHZXQgeW91
ciBwaWVjZSBvZiBoaXN0b3J5DQpub3chICBXZSB3b3VsZCBsaWtlIHRvIHNl
bmQgeW91IGEgRlJFRSBFdXJvDQphbmQgYSBGUkVFIHJlcG9ydCBvbiB3b3Js
ZCBjdXJyZW5jeS4gIEp1c3QgdmlzaXQNCm91ciBzaXRlIHRvIHJlcXVlc3Qg
eW91ciBFdXJvIGFuZCBFdXJvIHJlcG9ydDoNCg0KaHR0cDovL3ZpY2t5Lm1v
dGhvc3QuY29tL2V1cm8xLw0KDQpJbiBhZGRpdGlvbiB0byBvdXIgY3VycmVu
Y3kgcmVwb3J0LCB5b3UgY2FuIHJlY2VpdmUNCm91ciBGUkVFIElOVkVTVE1F
TlQgUEFDS0FHRToNCg0KKiAgTGVhcm4gaG93ICQxMCwwMDAgaW4gb3B0aW9u
cyB3aWxsIGxldmVyYWdlICQxLDAwMCwwMDAgaW4NCkV1cm8gQ3VycmVuY3ku
IFRoaXMgbWVhbnMgZXZlbiBhIHNtYWxsIG1vdmVtZW50IGluIHRoZSBtYXJr
ZXQNCmhhcyBodWdlIHByb2ZpdCBwb3RlbnRpYWwuDQoNCklmIHlvdSBhcmUg
b3ZlciBhZ2UgMTggYW5kIGhhdmUgc29tZSByaXNrIGNhcGl0YWwsIGl0J3MN
CmltcG9ydGFudCB0aGF0IHlvdSBmaW5kIG91dCBob3cgdGhlIEV1cm8gd2ls
bA0KY2hhbmdlIHRoZSBlY29ub21pYyB3b3JsZCBhbmQgaG93IHlvdSBjYW4g
cHJvZml0IQ0KDQpodHRwOi8vdmlja3kubW90aG9zdC5jb20vZXVybzEvDQoN
CiQxMCwwMDAgbWluaW11bSBpbnZlc3RtZW50DQoNClBsZWFzZSBjYXJlZnVs
bHkgZXZhbHVhdGUgeW91ciBmaW5hbmNpYWwgcG9zaXRpb24gYmVmb3JlDQp0
cmFkaW5nLiAgT25seSByaXNrIGNhcGl0YWwgc2hvdWxkIGJlIHVzZWQuDQoN
Cmh0dHA6Ly92aWNreS5tb3Rob3N0LmNvbS9ldXJvMS9vcHRvdXQuaHRtbCBU
byBPcHRPdXQuDQoNCg0KDQoNCg0KNjI3NGJyb2g5LTUyNmNUb2UzMDI2d25w
bTEtNDAwU1hFSTIwODBOVEVJNS0yNjFZZ1hpNTgxMG5WdU8xLTg0NkRRd3Iw
bDY1

[Firebird-test] sub select's

[news.clix.pt <ago...@cl...>]

Hi all

Why in a select procedure this don't work

     UPDATE inventario SET inventario.CUSTOMEDIO=(
              SELECT PRECOMEDIO FROM CUSTEIO  WHERE custeio.CODART = :CODART
AND CUSTEIO.tipo=0
                     AND custeio.custeioid=(
                       SELECT MAX(CUSTEIOID)
                       FROM CUSTEIO WHERE CUSTEIO.codart=:CODART AND
CUSTEIO.tipo=0 and CUSTEIO.data <=:DATAF)
                       )
            WHERE INVENTARIO.CODART = :CODART AND INVENTARIO.CODARM =
:CODARM AND inventario.util = USER;


and this works fine

            SELECT MAX(CUSTEIOID) FROM CUSTEIO
                   WHERE CUSTEIO.codart=:CODART AND CUSTEIO.tipo=0 and
                   CUSTEIO.data <=:DATAF
                   INTO :ID;

            SELECT PRECOMEDIO
              FROM CUSTEIO
              WHERE custeio.CODART = :CODART AND CUSTEIO.tipo=0
                AND custeio.custeioid=:ID INTO :QTMOV;

            UPDATE inventario SET inventario.CUSTOMEDIO=:QTMOV
            WHERE INVENTARIO.CODART = :CODART AND INVENTARIO.CODARM =
:CODARM AND inventario.util = USER;


is a bug?

thanks

ago...@cl...

[Firebird-test] ALTER UNIQUE INDEX INACTIVE;

[Skopalik S. <sko...@hl...>]

I was develop test by langref.pdf from www.ipphoenix.com
for alter index statament.

This doc say:
ALTER INDEX fails and returns an error if the index is defined for a UNIQUE, PRIMARY KEY,
or FOREIGN KEY constraint. To alter such an index, use DROP INDEX to delete the index,
then recreate it with CREATE INDEX.

but FB 1.0.0.821 alow inactivate unique index without any error.
Is it new feature or bug ?
If is feature then should be updated release notes or documentation.

	Slavek

ing. Slavomir Skopalik DEL a.s.
Olomoucka 355 Marianske udoli 783 75
Czech Republic
----------------------------------------------
Tel: 068 535 35 48
Mobil: 0602 795 874
Fax: 068 535 23 64
e-mail:sko...@hl...
http://hlubocky.del.cz

[Firebird-test] Step up to the plate 6918KvGC0-201lqVx1504WIzp-24

[<Vid...@ho...>]

PCEtLSBzYXZlZCBmcm9tIHVybD0oMDAyMilodHRwOi8vaW50ZXJuZXQuZS1t
YWlsIC0tPg0KPEhUTUw+PEhFQUQ+DQo8VElUTEU+SW5zdGEtQnJ1c2ggRGlz
cG9zYWJsZSBUb290aGJydXNoZXM8L1RJVExFPg0KPFNUWUxFPkE6bGluayB7
Y29sb3I6cmVkfTwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm
ZmZmZmY+DQo8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0xNCB3
aWR0aD02MDAgYm9yZGVyPTMgYm9yZGVyY29sb3JkYXJrPSMwMDMzNjYgYm9y
ZGVyY29sb3JsaWdodD0jNjY5OTk5IGJvcmRlcmNvbG9yPSMwMDMzNjY+DQog
IDxUQk9EWT4NCgk8VFI+DQoJPFREIHdpZHRoPTIwMCBiZ2NvbG9yPSM0Njgy
YjQgdmFsaWduPXRvcD48Rk9OVCBmYWNlPSJWZXJkYW5hLCBBcmlhbCIgY29s
b3I9I2ZmZmZmZiBzaXplPTQ+DQoJCTxCPkRPTidUIERSRUFNIFRPIExJVkUh
IC4uLjxCUj48QlI+TElWRSBUSEUgRFJFQU08L0I+PEJSPjwvRk9OVD4NCgkJ
PEZPTlQgZmFjZT0iVmVyZGFuYSwgQXJpYWwiIGNvbG9yPSNmZmZmZmYgc2l6
ZT0yPjxCUj48Qj4NCgkJPExJPkJlIHlvdXIgb3duIEJPU1MNCgkJPExJPldv
cmsgeW91ciBvd24gSE9VUlMNCgkJPExJPk5vIEZJWEVEIG92ZXJoZWFkDQoJ
CTxMST5IaWdoIENBU0ggcmV0dXJuIA0KCQk8TEk+SU5DT01FIFN1cHBsaW1l
bnQNCgkJPExJPlBhcnQgVGltZSBCdXNpbmVzczwvQj48L0ZPTlQ+PC9MST4N
Cgk8L1REPg0KICAgIDxURCAgd2lkdGg9NDAwPjxGT05UIGZhY2U9IlZlcmRh
bmEsIEFyaWFsIiBjb2xvcj0jMDAwMDUwIHNpemU9Mz4NCgkJPEI+RGVhciBG
dXR1cmUgQnVzaW5lc3MgT3duZXIsPC9CPiANCgkJPFAgYWxpZ249Y2VudGVy
PjxGT05UIGZhY2U9IlZlcmRhbmEsIEFyaWFsIiBjb2xvcj0jMDAwMDUwIHNp
emU9Mj4NCgkJWW91IGNhbiBub3cgZm9yIHRoZSBmaXJzdCB0aW1lLCBvd24g
YSBidXNpbmVzcyBpbiB5b3VyIGFyZWEgd2l0aCB0aGUgbW9zdCB1bmlxdWUs
IGlubm92YXRpdmUgcHJvZHVjdCBpbiBBbWVyaWNhIHRvZGF5LjxCUj48QlI+
DQoJCVdvcmsgbGVzcyB0aGFuIHRlbiBob3VycyBhIHdlZWsgd2l0aCB0aGUg
cG90ZW50aWFsIHRvIGVhcm4gJDUwLDAwMCBhIHllYXIuPEJSPjxCUj5IZXJl
J3MgaG93ISAgT3ZlciAzMDAgTWlsbGlvbiBwZW9wbGUgdXNlIHRoaXMgcHJv
ZHVjdCBpbiB0aGUgVS5TLg0KCQlkYWlseSwgdGhhdCdzIHJpZ2h0LCBvdmVy
IDMwMCBNaWxsaW9uIHBlb3BsZS48QlI+PEJSPlRoZSBwcm9maXQgbWFyZ2lu
IHdpdGggdXMgaXMgYW4gYW1hemluZyA0MDAlLCB5b3Ugd2lsbCBiZSBzYXlp
bmcNCgkJdG8geW91cnNlbGYgd2h5IGRpZG4ndCBJIHRoaW5rIG9mIHRoYXQh
PEJSPjxCUj4JQnJlYWsgZG93biB0aGUgd2FsbHMgYW5kIGxpdmUgdGhpcyBs
aWZlIHlvdSd2ZSBvbmx5IGRyZWFtZWQgYWJvdXQuPEJSPjxCUj4NCgkJTGVz
cyB0aGVuIDEwSyByZXF1aXJlZCB0byBnZXQgc3RhcnRlZC48QlI+QXZhaWxh
YmlsdHkgaW4geW91ciBhcmVhIGlzIGxpbWl0ZWQuPEJSPjxBIGhyZWY9Imh0
dHA6Ly93d3cubmV3dG9waWNzLmNvbS9JbnN0YS1CcnVzaC8iPg0KCQk8Qj5D
TElDSyBIRVJFIE5PVzwvQj48L0E+PEJSPlNvIHlvdSB0b28gY2FuIHJlY2Vp
dmUgeW91ciBmcmVlIGluZm9ybWF0aW9uIHBhY2thZ2UgdG9kYXkuDQoJCTxC
Uj48QlI+PEEgaHJlZj0iaHR0cDovL3d3dy5uZXd0b3BpY3MuY29tL0luc3Rh
LUJydXNoLyI+DQoJCTxGT05UIGZhY2U9IlZlcmRhbmEsIEFyaWFsIiBjb2xv
cj0jY2MzMzMzIHNpemU9NT48Qj48ST5Eb24ndCB3YWl0IGFueSBsb25nZXIh
PEJSPkdldCBTdGFydGVkIFRvZGF5ISE8L0k+PC9CPjwvRk9OVD48L0E+PC9G
T05UPjwvUD4NCgk8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjxCUj4NCjxU
QUJMRSB3aWR0aD01NTA+DQogIDxUQk9EWT4NCiAgPFRSID4NCiAgICA8VEQg
YWxpZ249Y2VudGVyPg0KCQk8SFIgU0laRT0xIHdpZHRoPSIxMDAlIiBjb2xv
cj1pbmRpZ28+DQoJCTxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEsIEFy
aWFsIj5Zb3VyIGVtYWlsIGFkZHJlc3Mgd2FzIG9idGFpbmVkIGZyb20gYW4g
b3B0LWluIGxpc3QuIE9wdC1pbiBNUlNBIExpc3QNCgkJPEJSPlB1cmNoYXNl
IENvZGUgIyAzMTItMjQwMS4gIElmIHlvdSB3aXNoIHRvIGJlIHVuc3Vic2Ny
aWJlZCBmcm9tIHRoaXMgbGlzdCwgcGxlYXNlIDxBIGhyZWY9Imh0dHA6Ly93
d3cubmV3dG9waWNzLmNvbS9yZW1vdmUvIiB0YXJnZXQ9Il9ibGFuayI+Y2xp
Y2sgaGVyZTwvQT48L2ZvbnQ+DQogICAgPC9URD48L1RSPjwvVEJPRFk+PC9U
QUJMRT48L0JPRFk+PC9IVE1MPg0KMzU4OGNPZ2c1LTk5OFdkVGI5NzkwellQ
cjEtNzg4RFduSTUzNzJVd1RzNS00NTBmR3hobDQ4

Re: [Firebird-test] Is this what you are looking for

[marius p. <ma...@re...>]

I will start with the stored procedures .
we could look at other open source db 
how they make the tests :posgress,mysql?


On Sat, 03 Aug 2002 11:26:02 -0700
Steve Landrum <st...@sl...> wrote:

> >
> >
> >Until to-do list would be ready, all test designers should claim their 
> >area of work in this list. I'll incorporate them in to-do list on the 
> >fly.
> >
> >Best regards
> >Pavel Cisar
> >http://www.ibphoenix.com
> >For all your upto date Firebird and
> >InterBase information
> >  
> >
> Then i'll start with table creation.  For the results should we query 
> the system tables to see if our table definitions went in correctly. 
>  Then test things like check constraints, index constraints, computed by 
> fields, etc.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-test

Re: [Firebird-test] Is this what you are looking for

[Pavel C. <pc...@us...>]

Hi,

On 3 Aug 2002 at 11:26, Steve Landrum wrote:

> Then i'll start with table creation.  For the results should we query 
> the system tables to see if our table definitions went in correctly. 
>  Then test things like check constraints, index constraints, computed by 
> fields, etc.

Yup, that's exactly the point. Your work would be greatly appreciated.

Best regards

Re: [Firebird-test] Is this what you are looking for

[Steve L. <st...@sl...>]

>
>
>Until to-do list would be ready, all test designers should claim their 
>area of work in this list. I'll incorporate them in to-do list on the 
>fly.
>
>Best regards
>Pavel Cisar
>http://www.ibphoenix.com
>For all your upto date Firebird and
>InterBase information
>  
>
Then i'll start with table creation.  For the results should we query 
the system tables to see if our table definitions went in correctly. 
 Then test things like check constraints, index constraints, computed by 
fields, etc.

Re: [Firebird-test] Is this what you are looking for

[Pavel C. <pc...@us...>]

Mark & all,

On 3 Aug 2002 at 16:36, Mark O'Donohue wrote:

> First it's important to identify what you want to test.
>
> Perhaps as a starter get the sql stmts from parse.y and break them into 
> stmts (or probably clauses).
>
> This will also make it easier to distribute the work amongst different 
> people without much duplication or overlap.
> 

You are right, but it's a helluva lot of work ! Making such a list will 
take some time, so we need to improvise a bit in meanwhile. I'm working 
on how-to's and to-do lists for web publishing (due date at the end of 
next week). That doesn't mean that work should stop until I finish it :) 
I'll answer all questions in this list, and any comments are more than 
welcome. I'm very happy about the interest the QA gets, but it's a work 
in progress, so forgive some chaotic steps please :)

Anyway, I'd like build tests in dependency order rather than statement 
order. For example, tests for ref. constraints would need table creation, 
table inserts and table scans for initialization and failure checks, so 
we need these tests first to assure validity of dependent tests.

I'm working on basic prerequisite tests to assure validity of empty 
database (data in system tables). That's connected to basic SELECT tests 
for selects from single table - for all or listed fields. All other areas 
are now open for all, but most needed tests right now are tests for 
creation of domains and tables (additional checks should use simple 
selects from system tables), for start without more complex clauses like 
PK, indexes etc. just various data types, row lengths etc.

That doesn't mean that tests for other areas are not welcome! We greatly 
appreciate any tests, but tests that are at the bottom of dependency 
graph would be implemented first. And after all, requirements for all 
tests would help us to map the dependencies (SQL space is huge :), so 
don't hesitate to design tests for area you know best.

> Then for each stmt, lets take FIRST/SKIP you need to identify all the 
> features of that stmt you want to test.
> 
> 1. range at start
> 2. range at end
> 3. range with subselect
> 4. range with no/incomplete data
> 5. illegal ranges
> 6 .range with sort
> etc.
> 
> The you design the tests to cover the above features, say 4. no 
> incomplete data
> 
> 4a select skip 10 first 5  - with zero data.
> 4b                                      - with 2 rows
> 4c                                     - with 7 rows
> 4c                                     - with 1 row
> 4c                                      - with 10 rows
> etc...
> 
> 
> That will give a bit more structure to you test process.  Focussing on 
> testing all the legal paths first - does it work correctly as specified.

Yes, that's the right way and exactly follow the prime directive - simple 
test cases, one aspect at a time. And positive tests first! Of course, 
some features like ref. constraints are better checked in negative tests.

Other big group of tests we need are test cases for each bug database 
entry. But these tests would be more complex, so we should defer them for 
now (with exception for really simple cases).

> To run this in a practical way you are going to need a list of who is 
> working on what stmt's or clauses, and you will need to assign and 
> identifiers to test features, test cases, etc.

Until to-do list would be ready, all test designers should claim their 
area of work in this list. I'll incorporate them in to-do list on the 
fly.

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information

Re: [Firebird-test] Is this what you are looking for

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

Hi Pavel

First it's important to identify what you want to test.

Perhaps as a starter get the sql stmts from parse.y and break them into 
stmts (or probably clauses).

This will also make it easier to distribute the work amongst different 
people without much duplication or overlap.

Then for each stmt, lets take FIRST/SKIP you need to identify all the 
features of that stmt you want to test.

1. range at start
2. range at end
3. range with subselect
4. range with no/incomplete data
5. illegal ranges
6 .range with sort
etc.

The you design the tests to cover the above features, say 4. no 
incomplete data

4a select skip 10 first 5  - with zero data.
4b                                      - with 2 rows
4c                                     - with 7 rows
4c                                     - with 1 row
4c                                      - with 10 rows
etc...


That will give a bit more structure to you test process.  Focussing on 
testing all the legal paths first - does it work correctly as specified.

Then revisiting the important illegal or negative test cases - does it 
screw up when given wrong stuff.  But these are endless, so complete 
coverage here is not

There is more in a similar style, on integration, stress, and system 
testing, and feature lists can be got from other sources, (usually they 
get pulled out as a list from user requirements, functional spec, 
program spec etc) but the above procedue is good enough for a basic test 
suite covering the required functionality.

To run this in a practical way you are going to need a list of who is 
working on what stmt's or clauses, and you will need to assign and 
identifiers to test features, test cases, etc.

Cheers

Mark

Re: [Firebird-test] Is this what you are looking for

[Steve L. <st...@sl...>]

>
>
>If want to contribute with tests 
>could we split in two the areas of testing so i don't write 
>again the same test .
>  
>
Sounds good to me.  What would you like me to start on?

Re: [Firebird-test] Is this what you are looking for

[marius p. <ma...@re...>]

If want to contribute with tests 
could we split in two the areas of testing so i don't write 
again the same test .
> 
> > Is this the type of thing you are looking for?
> 
> Almost there :-) In future, divide test to next sections: id, 
> description, dependencies, test type (positive / negative, yours is 
> negative), input, tested command, result, additional checks
> 
> For example:
> 
> Test ID: LANDRUM_001 (your name + your own sequence number)
> 
> Test type: NEGATIVE (i.e. must fail / return an error code)
> 
> Description:
> Check for proper enforcement of PK constraint - uniqueness of PK value.
> 
> Dependencies: (What tests must be run before this test. Use test IDs or 
> description)
> 
> - Table creation
> - Direct data insert
> 
> Prerequisites:
> 
> - New database (you can also refer to a database/script used in another 
> test by test ID)
> 
> - Initialization script:
> 
> CREATE TABLE FB_TEST(FB_ID INTEGER NOT NULL,
> FB_DATA VARCHAR(20),
> CONSTRAINT FB_ID_PK PRIMARY KEY (FB_ID));
>  
> INSERT INTO FB_TEST(FB_ID, FB_DATA)
> VALUES(1, 'RECORD ONE');
>  
> INSERT INTO FB_TEST(FB_ID, FB_DATA)
> VALUES(2, 'RECORD TWO');
> 
> Tested command:
>  
> INSERT INTO FB_TEST(FB_ID, FB_DATA)
>  VALUES(2, 'RECORD TWO');
> 
> Expected result:
>  
>  /*RESULT
>  Statement failed, SQLCODE = -803
>  violation of PRIMARY or UNIQUE KEY constraint "FB_ID_PK" on table 
> "FB_TEST"
>  */
> 
> Additional checks: NONE
>  
> 
> Thank you for your assistance!
> Pavel Cisar
> http://www.ibphoenix.com
> For all your upto date Firebird and
> InterBase information
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-test

Re: [Firebird-test] Is this what you are looking for

[Pavel C. <pc...@us...>]

Hi,

On 1 Aug 2002 at 21:04, Steve Landrum wrote:

> Is this the type of thing you are looking for?

Almost there :-) In future, divide test to next sections: id, 
description, dependencies, test type (positive / negative, yours is 
negative), input, tested command, result, additional checks

For example:

Test ID: LANDRUM_001 (your name + your own sequence number)

Test type: NEGATIVE (i.e. must fail / return an error code)

Description:
Check for proper enforcement of PK constraint - uniqueness of PK value.

Dependencies: (What tests must be run before this test. Use test IDs or 
description)

- Table creation
- Direct data insert

Prerequisites:

- New database (you can also refer to a database/script used in another 
test by test ID)

- Initialization script:

CREATE TABLE FB_TEST(FB_ID INTEGER NOT NULL,
FB_DATA VARCHAR(20),
CONSTRAINT FB_ID_PK PRIMARY KEY (FB_ID));
 
INSERT INTO FB_TEST(FB_ID, FB_DATA)
VALUES(1, 'RECORD ONE');
 
INSERT INTO FB_TEST(FB_ID, FB_DATA)
VALUES(2, 'RECORD TWO');

Tested command:
 
INSERT INTO FB_TEST(FB_ID, FB_DATA)
 VALUES(2, 'RECORD TWO');

Expected result:
 
 /*RESULT
 Statement failed, SQLCODE = -803
 violation of PRIMARY or UNIQUE KEY constraint "FB_ID_PK" on table 
"FB_TEST"
 */

Additional checks: NONE
 

Thank you for your assistance!
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information

[Firebird-test] Is this what you are looking for

[Steve L. <st...@sl...>]

Is this the type of thing you are looking for?


CREATE TABLE FB_TEST(FB_ID INTEGER NOT NULL,
FB_DATA VARCHAR(20),
CONSTRAINT FB_ID_PK PRIMARY KEY (FB_ID));

INSERT INTO FB_TEST(FB_ID, FB_DATA)
VALUES(1, 'RECORD ONE');

INSERT INTO FB_TEST(FB_ID, FB_DATA)
VALUES(2, 'RECORD TWO');

INSERT INTO FB_TEST(FB_ID, FB_DATA)
VALUES(2, 'RECORD TWO');

/*RESULT
Statement failed, SQLCODE = -803
violation of PRIMARY or UNIQUE KEY constraint "FB_ID_PK" on table "FB_TEST"
*/

[Firebird-test] ADV:Access cards 6157qUCz0-360qBSJ2217-20

[<FRE...@tf...>]

RECIEVE ALL CHANNELS ON YOUR SATELLITE SYSTEM! 1-888-406-4246

With our Pre-Programmed Satelite Cards get ALL channels
availible including ALL Pay-Per-View channels!!

Never miss any of your favorite shows again!

Our Pre-Programmed Access Cards work on ALL Satellite Systems!

Our pre-programmed satellite cards are $329.00 and are
shipped FedEx 2-Day COD Delivery!

Comes with a 30-Day Money Back Guarantee, 3 Year Warranty
and a 24-hour tech support line available!

Take your old card out, replace it with your new one
and receive everything available!  It's that easy!
-------------------------------------------------------------

Order yours TODAY by calling 1-888-406-4246






This message will only be sent to you once. 
You will not receive any future updates.
Any questions please call 1-888-406-4246.






3954LFsM6-896akFC3416cZuK5-068MBYql32

Re: [Firebird-test] WBT: Peer Review

[Jason C. (JAC2) <ja...@ja...>]

Pavel,

just my 2c.

> Current status:
> We have that system already in place, because many changes made to the
> Firebird source tree are subject of review by at least one developer. But
> at least some (I hope that only some) changes are not checked at all.
> Actually, we haven't any shared knowledge, that peer review is really
> utilized in our project. Of course, some bugs were catched that way, but
> we don't know from others to what degree they do the review of changed
> code (if at all). There is not any developer designated to this task.
>
> Questions for you:
> 1) Do you think that we should use peer review ?
Definately, attacking quality from black box (it does what it says it should
do) and visual inspection (it works, but boy does is do a bad job of it or
leaks like crazy or won't work on the 29th Feb) give the best chance of
catching bugs IMO.
>
>
> 2) If yes, is the current state satisfactory for you ?
Not really as the real value comes when you can sit in your Project manager
/ Risk managers chair and feel comfortable that you have the following:
1) Coverage - i.e. every line of code has had someone eye over it.
2) Quality Review - Pavel developed a bit of code that had a certain bug in
it and Jason reviewed it and didn't find it.  Report on code that Jason has
been the sole reviewer for optional re-review.
3) One piece of code has been reviewed by no-one and another has been
reviewed by everyone under the sun.

>
> 3) If not, what changes do you recommend ?
A coverage matrix / DB / whatever that allows the coder to leave their mark
(as it probably does now in cvs) + the ability for the reviewer to leave
their mark that they have reviewed it, then prior to release a risk
assesment can be made and any spare volunteer hours can be allocated to un
reviewed areas of the code.

>
>
> Your comments would be greatly appreciated.
> Best regards

Finally where I have been responsibel for setting up peer reviews, people
have ended up reviewing style over symantics, which doesn't help much.

Cheers,

JAC.

[Firebird-test] SQL compliance tests

[Pavel C. <pc...@us...>]

Hi all,

For those who'd like help us develop new tests, here is a brief how-to 
(more detailed one is in development :) for test designers.

What we need most right now are SQL compliance tests. Actually, it's not
necessary to write them, just design them. That mean:

1) Get FB/IB SQL reference guide.

2) Design really simple test cases, i.e. only single aspect of single 
command is tested in each test. Test consists from required input 
(database content), single SQL command and result check. Result check is
an actual result (i.e. from SELECT statement, error code etc.) and 
verification from database content (for INSERT statement and the likes). 
DDL commands are checked against system tables. Check may query more than
one table. This design may be written in plain, structured text (name, 
description, required input (ISqL script is best), tested statement, 
expected result - if any, commands and their expected output for result 
check (captured output from ISQL is enough).

3) Start from simple cases to more complex.

4) Send each test design in separate message to firebird-test mailing 
list for peer review and to get them implemented by test developers.

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information

Re: [Firebird-test] [IBDI] Invitation to disscussion about Firebird QA

[marius p. <ma...@re...>]

hello what is the status of the "TCS" test 
i want to help kylix/delphi/cpp/perl or python(beginner) 
there is some documentation?




On Wed, 5 Jun 2002 14:30:21 +0200
"Pavel Cisar" <pc...@ib...> wrote:

> Hi all,
> 
> Because Firebird Project is about to completely switch all development to 
> new source tree (called Firebird 2) converted from C to C++, and large 
> changes in engine subsystems are planned or already implemented (like new 
> memory management, use of exceptions, database aliases etc.), the 
> effective QA is more important than ever.
> 
> You may know that along with IB, Borland open-sourced a test control 
> system (with few hundred tests) for it called TCS (available as a 
> separate project on SF or in Firebird's cvs repository). This test 
> harness is able to run on multiple platforms (is written in C) and is 
> used by Firebird Project to test every official Firebird release. But the 
> total amount of tests is small (Borland released only a small subset of 
> all available tests), and because tests are mostly written in C and ESQL, 
> and with extensive use of tools like QLI, ISQL etc., it's very hard for 
> arbitrary developer to change or write new tests. One must have skills 
> and knowledge at least as any core engine developer, and in many cases 
> much deeper.  Many tests are also poorly designed, and the usability of 
> test reports is questionable (it's very hard to decipher the exact reason 
> of any failure and failures are often false, i.e. test environment 
> errors). Under given circumstances, it's impossible to use TCS as a 
> framework for Firebird QA in scale we need it. We were aware of that for 
> long time, and after months of internal R&D it finally seems that we have 
> a solution ready for use.
> 
> As a core test framework, we'd like try to use the QMTest - an open 
> source test tool written in Python by CodeSourcery (available at 
> http://www.codesourcery.com). QMTest has a CLI and Web interface, is able 
> to perform distributed testing, tests and test resources are stored in 
> XML files suitable for cvs and much more. The most important thing for us 
> is that's able to run on any platform where Python is available (AFAIK 
> all platforms supported by Firebird) and that test could be written in 
> any language. We'd like to use Python with kinterbasdb or gvib for access 
> to FB (both are also open source packages) for core SQL tests, but some 
> test could (or must) be written in other languages like Java, C/C++, 
> Delphi/Kylix etc.
> 
> Because we're about to build the whole new suite of tests, we would 
> greatly appreciate ANY help. If you're willing to share your expertise 
> about automatic testing, Python, Java, C/C++, SQL, or even better, if 
> you're willing to DESIGN (Python is not necessary, just SQL) or WRITE 
> some tests (mostly in Python, but Python is beautiful and simple 
> language, and writing tests is not hard, just boring :), please join us 
> in Firebird-test mailing list (subscription details:  
> http://www.firebirdsql.org/fbnew/index.php?op=lists#fb-test)
> 
> Best regards
> Pavel Cisar
> There is nothing wrong with InterBase
> that Firebird can't fix for you
> http://www.firebirdsql.org
> 
> 
> Community email addresses:
>   Post message: IB...@ya...
>   Subscribe:    IBD...@ya...
>   Unsubscribe:  IBD...@ya...
>   List owner:   IBD...@ya...
> 
> Shortcut URL to this page:
>   http://www.yahoogroups.com/community/IBDI 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Firebird-test mailing list
> Fir...@li...
> https://lists.sourceforge.net/lists/listinfo/firebird-test

[Firebird-test] SQL_EVENT_13 fails with GCC 3.1

[Erik K. <Eri...@ph...>]

Hi,

the TCS test SQL_EVENT_13 fails on systems with GCC 3.1 with the following
compile error:

 event_custom.h:61:1: directives may not be used inside a macro argument
> event_custom.h:60:39: unterminated argument list invoking macro "PROTO"
> In file included from event_client.e:12:
> event_custom.h:61: parse error before "PROTO"
> event_custom.h:64: syntax error before "int"
> event_custom.h:69:1: directives may not be used inside a macro argument
> event_custom.h:68:41: unterminated argument list invoking macro "PROTO"
> event_custom.h:69: parse error before "PROTO"
> event_custom.h:72: syntax error before "int"
[...]

How do I open a bug-report?


-- 
   Dipl.-Ing. Erik Kunze               Phone: +49 - 89 - 32 14 07 41
   PHILOSYS Software GmbH              Fax:   +49 - 89 - 32 14 07 12
   Edisonstr. 6                        Email: Eri...@ph...
   D-85716 Unterschleissheim           WWW:   www.philosys.de/~kunze

 PGP-Key: http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xD5759581

[Firebird-test] In 24 Hrs You can accept credit cards 4038VJHA9-139BDiH2305ebcZ5-31-27

[<kst...@ya...>]

DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u
dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2
Ij5TaG9wcGVycyBXYW50IHRvIENoYXJnZSBUaGVpciBQdXJjaGFzZXM8L2Zv
bnQ+PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxzdHJv
bmc+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xvcj0iIzAwMDA4MCIg
c2l6ZT0iNiI+TWFrZSBTdXJlIFRoZXkgQXJlIEJ1eWluZyBmcm9tIFlvdSE8
L2ZvbnQ+PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJsZWZ0Ij4gPHN0
cm9uZz4gPGZvbnQgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5UaGUg
ZmFjdHMgYWJvdXQgdG9kYXkncyBjb25zdW1lcjo8L2ZvbnQ+IDwvc3Ryb25n
Pg0KICA8Zm9udCBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPiBIZSBv
ciBzaGUgaXMgYSBmYXN0LXBhY2VkLCBvbi10aGUtZ28sICJJIHdhbnQgaXQg
bm93IiBraW5kIG9mIHNob3BwZXIuIFRoZWlyIHdhbGxldHMgYXJlIHN0dWZm
ZWQgZnVsbCBvZiBjcmVkaXQgY2FyZHMsIGFuZCB0aGUgY2hlY2tib29rIGlz
ICB1c3VhbGx5IG5vd2hlcmUgdG8gYmUgZm91bmQuPC9mb250Pg0KPGRpdiBh
bGlnbj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6IDA7IG1hcmdpbi1yaWdodDogMCI+PGI+PGZvbnQgY29sb3I9IiNmZjAw
MDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+VEhFU0UNCiAgU0hP
UFBFUlMgQVJFIEVWRVJZV0hFUkUhPC9mb250PiA8L2I+PC9kaXY+DQo8ZGl2
IGFsaWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46
IDAiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVi
dWNoZXQgTVMiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNh
cHMiPm9uDQogIHRoZSB3ZWI8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlRy
ZWJ1Y2hldCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwt
Y2FwcyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxpZ249
ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+PGZv
bnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBN
UyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+b24N
CiAgdGhlIHBob25lPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxpZ249
ImxlZnQiPjxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9u
dCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1T
Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5pbg0K
ICB0aGUgYXV0byBzaG9wPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgYWxp
Z249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjogMCI+
PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hl
dCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2FwcyI+
YXQNCiAgdGhlIGdpZnQgc2hvcDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2
IGFsaWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46
IDAiPjxiPjxmb250IGNvbG9yPSIjZmYwMDAwIiBmYWNlPSJUcmVidWNoZXQg
TVMiIHNpemU9IjUiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxs
LWNhcHMiPkVWRVJZV0hFUkUhPC9zcGFuPjwvZm9udD48L2I+PC9kaXY+DQo8
ZGl2IGFsaWduPSJjZW50ZXIiPjxwIGFsaWduPSJsZWZ0Ij48ZW0+PGZvbnQg
c2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+
QWxsIFJldGFpbCxXaG9sZXNhbGUsIE9yZGVyIENlbnRlcnMsIE1haWwtT3Jk
ZXIgQnVzaW5lc3MsIENvbnN0cnVjdGlvbiBUcmFkZXMsIGFuZCBTZXJ2aWNl
IFByb3ZpZGVycyBuZWVkIHRvIGFjY2VwdCBjcmVkaXQgY2FyZHMhPC9mb250
PjwvZW0+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxwPjwvZGl2Pg0K
PGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250
LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPjxlbT48ZGZuPjxmb250IGNvbG9yPSIj
RkYwMDAwIiBzaXplPSIzIiBmYWNlPSJUcmFqYW4iPk92ZXINCiAgOTIlIG9m
IG1haWwgb3JkZXJzICZhbXA7IHBob25lIG9yZGVycyBhcmUgZG9uZSB3aXRo
IGNyZWRpdCBjYXJkcy48L2ZvbnQ+PC9kZm4+PC9lbT48L3NwYW4+PC9zdHJv
bmc+PC9kaXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPiA8L2Rpdj4NCjxmb250
IHNpemU9IjQiPjxoMSBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxp
Z249ImNlbnRlciI+PHNwYW4gc3R5bGU9IkZPTlQtU0laRTogMTRwdDsgbXNv
LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxmb250IGNvbG9yPSIjMDAwMDgw
IiBmYWNlPSJUcmFqYW4iIHNpemU9IjUiPjxiPldoeSBOb3QgSW5jcmVhc2Ug
eW91ciBzYWxlcyBieSA0MDAlPzwvYj48L2ZvbnQ+PC9zcGFuPjwvaDE+DQo8
cCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249ImNlbnRlciI+
Jm5ic3A7PC9wPjwvZm9udD4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9u
Zz48Zm9udCBmYWNlPSJUcmFqYW4iIHNpemU9IjQiIGNvbG9yPSIjRkYwMDAw
Ij48aT5ZT1UgQ0FOIEJFR0lOIEFDQ0VQVElORyBDUkVESVQgQ0FSRFMgSU4g
QVMgTElUVExFIEFTIDI0IEhPVVJTITwvaT48L2ZvbnQ+PC9zdHJvbmc+PC9k
aXY+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxmb250IGZhY2U9IlRyZWJ1Y2hl
dCBNUyIgc2l6ZT0iNCIgY29sb3I9IiMwMDAwMDAiPihEZXBlbmRpbmcgdXBv
biB0aGUgY3JlZGl0IGNhcmQgIHByb2dyYW0gd2UgZ2V0IHlvdSBxdWFsaWZp
ZWQgZm9yKTwvZm9udD4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iNCI+PGZvbnQg
ZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNSI+PGZv
bnQgZmFjZT0iVHcgQ2VuIE1UIiBzaXplPSI1Ij48ZGl2IGFsaWduPSJjZW50
ZXIiPjxiPjxmb250IHNpemU9IjUiIGZhY2U9IlRyZWJ1Y2hldCBNUyIgY29s
b3I9IiMwMDAwODAiPlZpc2EsIE1hc3RlckNhcmQsIEFtZXJpY2FuIEV4cHJl
c3MsIERpc2NvdmVyPC9mb250PjwvYj48L2Rpdj4NCjxkaXYgYWxpZ249ImNl
bnRlciI+PC9kaXY+PC9mb250PjwvZm9udD4NCjxoNCBzdHlsZT0iTUFSR0lO
OiAwaW4gMGluIDBwdCIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IlRyZWJ1
Y2hldCBNUyIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjQiPlNhbWUgZGF5IGFw
cHJvdmFsIC0gbm8gdHVybiBkb3ducyAtIGVhc3kgZmF4IGFwcGxpY2F0aW9u
PC9mb250PjwvaDQ+PGg0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBh
bGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0IE1TIiBzaXplPSI0
Ij48c3BhbiBzdHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxm
b250IGNvbG9yPSIjMDAwMDAwIj5SZXRhaWw8L2ZvbnQ+PGZvbnQgY29sb3I9
IiNGRjAwMDAiPio8L2ZvbnQ+DQo8Zm9udCBzaXplPSI1IiBmYWNlPSJUdyBD
ZW4gTVQiIGNvbG9yPSIjMDAwMDAwIj5XZWIgVmlydHVhbCB0ZXJtaW5hbCA8
L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRjAwMDAiPio8L2ZvbnQ+DQo8Zm9udCBj
b2xvcj0iIzAwMDAwMCI+TWFpbCBvcmRlcjwvZm9udD48Zm9udCBjb2xvcj0i
I0ZGMDAwMCI+KjwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+IFRlbGVw
aG9uZSBvcmRlcjwvZm9udD48L3NwYW4+PC9mb250PjxzdHJvbmc+PHNwYW4g
c3R5bGU9Im1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij48Zm9udCBzaXpl
PSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAwMDAwIj48TzpQ
Pg0KPC9POlA+PC9mb250Pjwvc3Bhbj48L3N0cm9uZz48L2g0Pg0KICA8aDQg
c3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFsaWduPSJsZWZ0Ij48Zm9u
dCBmYWNlPSJUcmVidWNoZXQgTVMiIHNpemU9IjQiPkV4aXN0aW5nIE1lcmNo
YW50czogPGk+PGZvbnQgZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAw
MCIgc2l6ZT0iNSI+TG93ZXIgeW91ciByYXRlcyAtLUZSRUUgc3RhdGVtZW50
IGFuYWx5c2lzPC9mb250PjwvaT48L2ZvbnQ+DQogIDwvaDQ+DQo8UD48Zm9u
dCBzaXplPSIrMiIgZmFjZT0iVHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCI+
PGEgaHJlZj0iaHR0cDovL3d3dy5sb3dlc3QtcmF0ZS5uZXQvY2dpLWJpbi9t
ZXJjaGFudF9zZXJ2aWNlcy5jZ2k/YWZmaWxpYXRlPTU1MDQ2MyI+IEp1c3Qg
Q2xpY2sgSGVyZSB0byBTdGFydCBBY2NlcHRpbmcgQ3JlZGl0IENhcmRzIFJp
Z2h0IEF3YXkhPC9hPiAgDQo8cD5BIHJlcHJlc2VudGF0aXZlIHdpbGwgY29u
dGFjdCB5b3Ugd2l0aGluIDI0IGhvdXJzITwvZm9udD4NCjxmb250IGZhY2U9
IlR3IENlbiBNVCIgY29sb3I9IiMwMDAwMDAiIHNpemU9IjUiPg0KPFA+PGZv
bnQgZmFjZT0iQXJpYWwiIHNpemU9IjMiPg0KSnVzdCBWaXNpdCBPdXIgV2Vi
c2l0ZSB0byB0YWtlIHlvdXIgbmFtZSBvdXQgb2Ygb3VyIG1hc3RlciBkYXRh
YmFzZS4NCjxmb250IGNvbG9yPSJmZmZmZmYiPg0KPHA+DQo8L2Rpdj4NCg0K
PC9oND4NCg0KPC9odG1sPg0KMTY4MGw0

Re: [Firebird-test] On Testing

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

Hi Pavel

Pavel Cisar wrote:

>  
>
>Exactly, that is where I'd like to start !!! Actually, we don't need to 
>begin with adaptation of TCS tests - they work fine in TCS once you 
>managed to run them, but we need fresh new tests and SQL compliance tests 
>are best candidate. What's the REAL problem with new tests is HOW to 
>design them, and WHAT environment provide for test writers to make their 
>work easy (so more people can write tests) and productive (more test 
>would be written in next few months).
>
The real problem with test cases, is not writing them, its handling the 
output.  The crucial areas being:

1) parsing output data.
The system needs to be robust enough to handle changes in 
environment/format (for example Claudio's better error handling broke 
80% of the TCS test, since the output changed slightly).  So look 
carefully at the output parsing mechanisms,  The dejagnu/expect one is 
fairly good, you pattern match on what you want it ignores the rest. TCS 
does a simple diff on it's output, but more flexible one is desirable - 
for example in expect to test first/skip clauses, I just counted number 
of records returned, rather than match all output.

2) reviewing differences
When output differs from prior run, a good comparison method is needed 
(diff is good) but tcs comparison is poor (mainly since it splits stdio 
and stderror).  Flat files for data & results also help versioning.

Im not real worried about a gui, I just want to do:

 $make test.
and a diff for output

Much like junit (which I rather like), although we're not really in a 
position to use it.

Test design and init scripts and test groups etc, are not really big 
issues, when you get into it.



> Both questions are connected, but 
>HOW is more important and not related to tools we use, but to DESIGN of 
>tests. For example: How we can test CREATE TABLE statement ? Well, 
>statement can pass ok, but how we can verify that table was created 
>
The How is as follows, your test should involve script to check the 
results.  In expect something like:

expect_results = "TEST                  NUMERIC(18,0) Not Null";

send "create table fred (test integer);"
expect $prompt
send "show table fred;"

result = ""
expect {
       "$prompt":  break;
      "^*\n"  :     result = $result + currentLine
      -timeout :
}

if $result <> $expect_result) then
    fail_test "unexpected results"
fi

Other scripting things shouldbe similar, (Course if your smart you'll 
put the results into a file, and paramaterise the input).  How you 
organise the into groups/modules etc is then up to you.   It's simple 
but effective and very flexible.  

Even if you have a gui, loadrunner, QAtest and all those guys all end up 
with a script interface.

Btw: you should check for a python interface to dejagnu, it wouldn't 
supprise me if there was something there.

Im not religious about the tcl/expect but I didn't see anything better 
that covered the basics, and some of those other options cost lots of 
money - but if you find something I willing to listen.

Cheers

Mark

>  
>

Re: [Firebird-test] On Testing

[Pavel C. <pc...@us...>]

Mark,

On 5 Jul 2002 at 9:31, Mark O'Donohue wrote:

> I'd only consider looking at a new tool, once someone was convinced 
> enough and dedicated enough to actually port the existing tests to 
> whatever new system.  

Actually, I'm that person :) But as I explained in an answer to John 
Bellardo, it's only a starter and not the most important, as current TCS 
tests do not cover the most important areas. The problem is not ESQL, 
TCS, dejagnu or whatever, as I'm willing to learn anything to write tests 
(I had to start learning Python just to play with QMTest customization), 
but the fact that test writing is not a task for single man, because we 
need far more tests than +-400. We need at least ten times more to match 
the Borland's "certification" process. And this is the target I'm working 
on - build a system that can be compared to Borland's QA and exceed it. 
Anything less is IMHO near to waste of resources.

> Following that I'd say take the SQL grammar in parse.y walk through all 
> the tests, perhaps interacting with ib-support / ibdi groups for 
> examples and make sure we have coverage of all SQL statements.

Exactly, that is where I'd like to start !!! Actually, we don't need to 
begin with adaptation of TCS tests - they work fine in TCS once you 
managed to run them, but we need fresh new tests and SQL compliance tests 
are best candidate. What's the REAL problem with new tests is HOW to 
design them, and WHAT environment provide for test writers to make their 
work easy (so more people can write tests) and productive (more test 
would be written in next few months). Both questions are connected, but 
HOW is more important and not related to tools we use, but to DESIGN of 
tests. For example: How we can test CREATE TABLE statement ? Well, 
statement can pass ok, but how we can verify that table was created 
correctly ? By reading system tables ? By populating it with data and  
verification of those data ? By other way ? What are dependencies among 
tests ? For example, we should test the SELECT from system tables first 
to trust results of CREATE TABLE test based on system tables scan. 

Actually, writing test could be task for few, because the hard and most 
time consuming part is the correct test design. We should provide some 
guidelines for test _designers_ how to design tests and how to write this 
design down for test writers. These quidelines can come only from engine 
developers, because they know the dependencies in the code, but then, 
_anyone_ can design new tests that others then implement. If anyone has 
any idea about test design (general or for particular test area), don't 
hesitate to share it !

> (I think doxygen blew a stack on the original fb code, but it and fb2 
> have evolved a little - and Im happy to try again since it'd be useful).

I've noticed only one doxygen short-coming - it's too object oriented 
(aah, so nice class diagrams :-), so the generated doc is not very well-
arranged for code that have a billion of functions and only few classes. 
But maybe I've just overlooked some magic option switch :-)

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information

[Firebird-test] On Testing

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

Hi

Im interesting in using tools that work for testing/documenting.

Im not fussed if extra software needs to be installed to run testing, 
since only a few are really interested in running the tests, but it has 
to be available to run on all platforms.

[And remember win32 was the last platform that we got to run tcs on 
(thanks to Paul Reeves), prior to that dispite our apparently large 
win32 following noone had tried (or succeeded).]

So unless someone is going to do a lot of work, I'd recommend following 
up on the dejagnu thing, it has the advantage of already running most of 
the TCS tests and is more flexible than the TCS program.  

I'd only consider looking at a new tool, once someone was convinced 
enough and dedicated enough to actually port the existing tests to 
whatever new system.  

Following that I'd say take the SQL grammar in parse.y walk through all 
the tests, perhaps interacting with ib-support / ibdi groups for 
examples and make sure we have coverage of all SQL statements.

(I think doxygen blew a stack on the original fb code, but it and fb2 
have evolved a little - and Im happy to try again since it'd be useful).

Cheers

Mark

RE: [Firebird-test] WBT: Code Audit

[Leyne, S. <sl...@at...>]

> Hold the horses ! I don't know what instructions you've read...

I'd like permission to remove the foot from my mouth...


Sean