Le 13 juin 06 à 11:49, Robert Garcia a écrit :
If you plan on staying with witango, I would seriously recommend
moving to 5.5, what is the bug in directDBMS you are dealing with?
There may be a workaround.
This bug is that :
========================================================
I use on Mac OS X (Panther) + MySQL 4.1 + MyODBC + WiTango Server 5.0
on production server.
I have a host for WiTango server and a host for MySQL server.
When i use a Direct DBMS action, to get the "total rows" i use this
method (this is a "work around" because in the Direct DBMS Action the
<@TOTALROWS> tag value is always "-1" :
- First Direct DBMS action :
SELECT SQL_CALC_FOUND_ROWS ...
- Second Direct DBMS action :
SELECT FOUND_ROWS();
and this action return the "total rows" value.
It work's fine with WiTango 5.0 server version
BUT with WiTango 5.5.009 server version, the fist action return the
records but the second action return 0 (and the <@TOTALROWS> tags
return always -1).
And i send the request to the same MySQL server
- with the same version of MyODBC (MySQL ODBC Driver 3.51)
- the same version of Panther (10.3.9) and ODBC tools (v 1.0.1) on
the WiTango 5.5 and WiTango 5.0 hosts.
The unique difference is the version of WiTango server...
I have made a test with command line tool "odbctest" on the WiTango
5.5 host :
- First command
SELECT SQL_CALC_FOUND_ROWS ... --> i get the list of records
- Second command
SELECT FOUND_ROWS(); --> I get the (good) count of total records.
========================================================
(next in thread)
SQL_CALC_FOUND_ROWS and SELECT_FOUND_ROWS() have a different intent
-- they determine total rows matching the criteria, but WITHOUT the
LIMIT clause. EG. Displaying 25 (LIMIT) out of 233 (FOUND ROWS).
Yes. SELECT_FOUND_ROWS() return the same value that <@Totalrows> tag.
It's also meant to avoid re-running the query.
And it's very important on a production server.
I have made another tests with WiTango 5.5 against WiTango 5.0.
I create a very simple .taf file with 2 Direct DBMS actions :
1/ SELECT SQL_CALC_FOUND_ROW FROM ... WHERE ... ORDER BY ...
2/ SELECT FOUND_ROWS();
and i make a TCP Dump on the WiTango server to look the requests sent
to MySQL server.
Here the result of TCP Dump file:
Note : "etabdatacomp" id the first table of my database. It is empty.
WiTango 5.0
-----------
Select 1 from etabdatacomp;
SELECT SQL_CALC_FOUND_ROW ...
SELECT FOUND_ROWS();
It's work fine : The SELECT return the list of records (with LIMIT
property) and the FOUND_ROWS() the count of records selected (with no
limit)
WiTango 5.5
-----------
Select 1 from etabdatacomp;
SELECT SQL_CALC_FOUND_ROW ...
Select 1 from etabdatacomp;
SELECT FOUND_ROWS();
It doesn't work because the second "Select 1 from etabdatacomp;"
return an empty selection and the SELECT FOUND_ROWS() return 0
I will be make a bug report on the WiTango web site. I hope that this
bug will be corrected in the next release.
========================================================
And this bug have a "partial" workaround... :
The SELECT FOUND_ROWS() request return always 0 but...
If i put the system variable CACHE in witango.ini file on TRUE, it
works fine EXCEPT on the first call of .taf file...
And every time the .taf file is not in cache, the first call failed.
All these bugs have been reported to witango bug support...
If you have a "total" workaround...
My Configuration :
WiTango 5.5 host
----------------
WiTango Server 5.5.009
Mac OS X 10.3.9
Apache 1.3.29
MyODBC (downloaded from mysql site) 3.51.11
MySQL Host
----------
Mac OS X 10.3.9
MySQL 4.1.12
Regards
Francis LEBOURQ
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
