From gambas at ...1... Thu Sep 3 14:21:50 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Thu, 3 Sep 2015 14:21:50 +0200 Subject: [Gambas-devel] [Gambas-user] Pre-release of Gambas 3.8.1 In-Reply-To: <55E835B3.8060705@...1...> References: <55E78CFC.4030101@...1...> <55E79879.4000507@...1...> <55E830B0.30508@...176...> <55E835B3.8060705@...1...> Message-ID: <55E83B5E.8020201@...1...> Le 03/09/2015 13:57, Beno?t Minisini a ?crit : > Le 03/09/2015 13:36, ML a ?crit : >> Beno?t, >> >> Any chance to include my modified ODBC component in the *3.8.1* release? >> Just in case, I'm attaching it. >> Only changed *main.c* in *gb.db.odbc/src*, just look for the string >> */zxMarce/* to find changes. Full comments, and I think I even got rid >> of a coupla SegFaults due to empty properties (Connection's .Host and >> .User/.Login). >> >> It still lacks the capability of returning a proper *Result* object (no >> data rows), but it does populate the *Result.Fields* property correctly. >> I've been investigating a bit and that may be a problem in the main (I >> mean *gb.db*) *CResult.c* file. Not 100% sure yet, though. >> >> Regards, >> >> *On 2015-09-02 21:46, Beno?t Minisini wrote:* >>> *Le 03/09/2015 01:57, Beno?t Minisini a ?crit : * >>>> Hi, >>>> As usual, here is a pre-release package of Gambas 3.8.1 at: >>>> http://sourceforge.net/projects/gambas/files/gambas3/gambas3-3.8.1.tar.bz2/download >>>> >>>> Please test it if possible, and report any problem before I make the >>>> release official. >>>> Regards, >>> The list of bug fixes is available now at >>> http://gambaswiki.org/wiki/doc/release/3.8.1 >>> Regards, >> *--** >> **zxMarce.* > > I'm currently merging it... Can I have your full name and your country > to put in the Gambas "Hall of Fame" developer list? > > Thanks. > Hi, In revision #7267, I have modified some of your changes: - I allowed Host to be null (i t is replaced by a void string) without an error message. - I simplified your is_host_a_connstring() function, and replaced a "|" by a "||" (you know the difference?) Tell me if you have questions. Regards, -- Beno?t Minisini From d4t4full at ...176... Thu Sep 3 14:53:49 2015 From: d4t4full at ...176... (ML) Date: Thu, 3 Sep 2015 09:53:49 -0300 Subject: [Gambas-devel] [Gambas-user] Pre-release of Gambas 3.8.1 In-Reply-To: <55E83B5E.8020201@...1...> References: <55E78CFC.4030101@...1...> <55E79879.4000507@...1...> <55E830B0.30508@...176...> <55E835B3.8060705@...1...> <55E83B5E.8020201@...1...> Message-ID: <55E842DD.2040803@...176...> Beno?t, Actually, I did not remember what the difference was between both operators until you asked. Don't tell me I used bitwise-or instead of logical-or! (*quick-source-check*) Oh boy... Yes I was (*blushes*). Ok, will now redownload the trunk version from SF and admire my (your?) work as a public thing. Also I'll see how you simplified the function, I knew there was room for that there. I like to learn this stuff. Thanks, On 2015-09-03 09:21, Beno?t Minisini wrote: > Le 03/09/2015 13:57, Beno?t Minisini a ?crit : >> Le 03/09/2015 13:36, ML a ?crit : >>> Beno?t, >>> >>> Any chance to include my modified ODBC component in the *3.8.1* >>> release? >>> Just in case, I'm attaching it. >>> Only changed *main.c* in *gb.db.odbc/src*, just look for the string >>> */zxMarce/* to find changes. Full comments, and I think I even got rid >>> of a coupla SegFaults due to empty properties (Connection's .Host and >>> .User/.Login). >>> >>> It still lacks the capability of returning a proper *Result* object (no >>> data rows), but it does populate the *Result.Fields* property >>> correctly. >>> I've been investigating a bit and that may be a problem in the main (I >>> mean *gb.db*) *CResult.c* file. Not 100% sure yet, though. >>> >>> Regards, >>> >>> *On 2015-09-02 21:46, Beno?t Minisini wrote:* >>>> *Le 03/09/2015 01:57, Beno?t Minisini a ?crit : * >>>>> Hi, >>>>> As usual, here is a pre-release package of Gambas 3.8.1 at: >>>>> http://sourceforge.net/projects/gambas/files/gambas3/gambas3-3.8.1.tar.bz2/download >>>>> >>>>> >>>>> Please test it if possible, and report any problem before I make the >>>>> release official. >>>>> Regards, >>>> The list of bug fixes is available now at >>>> http://gambaswiki.org/wiki/doc/release/3.8.1 >>>> Regards, >>> *--** >>> **zxMarce.* >> >> I'm currently merging it... Can I have your full name and your country >> to put in the Gambas "Hall of Fame" developer list? >> >> Thanks. >> > > Hi, > > In revision #7267, I have modified some of your changes: > > - I allowed Host to be null (i t is replaced by a void string) without > an error message. > > - I simplified your is_host_a_connstring() function, and replaced a > "|" by a "||" (you know the difference?) > > Tell me if you have questions. > > Regards, > From ron at ...572... Mon Sep 14 11:48:51 2015 From: ron at ...572... (Ron) Date: Mon, 14 Sep 2015 11:48:51 +0200 Subject: [Gambas-devel] https for gambaswiki/bugtracker Message-ID: Benoit, You can request a free (for open-source projects) SSL certificate here: https://www.globalsign.com/en/ssl/ssl-open-source/ You can extend it every year for free too. I have done the same for my site, and have a nice A+ rating. Better to protect your users credentials. Regards, Ron_2nd. From gambas at ...1... Mon Sep 14 12:49:58 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Mon, 14 Sep 2015 12:49:58 +0200 Subject: [Gambas-devel] https for gambaswiki/bugtracker In-Reply-To: References: Message-ID: <55F6A656.8000400@...1...> Le 14/09/2015 11:48, Ron a ?crit : > Benoit, > > You can request a free (for open-source projects) SSL certificate here: > https://www.globalsign.com/en/ssl/ssl-open-source/ > > You can extend it every year for free too. > > I have done the same for my site, and have a nice A+ rating. > Better to protect your users credentials. > > > Regards, > Ron_2nd. > Thanks, I will look at it! -- Beno?t Minisini From gambas at ...1... Mon Sep 14 12:57:53 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Mon, 14 Sep 2015 12:57:53 +0200 Subject: [Gambas-devel] https for gambaswiki/bugtracker In-Reply-To: <55F6A656.8000400@...1...> References: <55F6A656.8000400@...1...> Message-ID: <55F6A831.3080909@...1...> Le 14/09/2015 12:49, Beno?t Minisini a ?crit : > Le 14/09/2015 11:48, Ron a ?crit : >> Benoit, >> >> You can request a free (for open-source projects) SSL certificate here: >> https://www.globalsign.com/en/ssl/ssl-open-source/ >> >> You can extend it every year for free too. >> >> I have done the same for my site, and have a nice A+ rating. >> Better to protect your users credentials. >> >> >> Regards, >> Ron_2nd. >> > > Thanks, I will look at it! > I have sent a request. -- Beno?t Minisini From ron at ...572... Mon Sep 14 13:17:51 2015 From: ron at ...572... (Ron) Date: Mon, 14 Sep 2015 13:17:51 +0200 Subject: [Gambas-devel] https for gambaswiki/bugtracker In-Reply-To: <55F6A831.3080909@...1...> References: <55F6A656.8000400@...1...> <55F6A831.3080909@...1...> Message-ID: When enabling HSTS on your webserver side all of the recent browsers will redirect the users to HTTPS automatically. And google search had replaced my links in a day, they prefer the https urls too of course (higher ranking) Regards, Ron_2nd. 2015-09-14 12:57 GMT+02:00 Beno?t Minisini : > Le 14/09/2015 12:49, Beno?t Minisini a ?crit : >> Le 14/09/2015 11:48, Ron a ?crit : >>> Benoit, >>> >>> You can request a free (for open-source projects) SSL certificate here: >>> https://www.globalsign.com/en/ssl/ssl-open-source/ >>> >>> You can extend it every year for free too. >>> >>> I have done the same for my site, and have a nice A+ rating. >>> Better to protect your users credentials. >>> >>> >>> Regards, >>> Ron_2nd. >>> >> >> Thanks, I will look at it! >> > > I have sent a request. > > -- > Beno?t Minisini > > ------------------------------------------------------------------------------ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel From d4t4full at ...176... Mon Sep 14 17:41:47 2015 From: d4t4full at ...176... (ML) Date: Mon, 14 Sep 2015 12:41:47 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55DF51B8.6060706@...1...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> Message-ID: <55F6EABB.4050804@...176...> Beno?t, Continuing here as you requested. I found the problem in th driver that causes it to return 0 instead of -1 in the RowCount. The offending line and my patch: //20150914 - zxMarce: Do NOT mark the STMT as Scrollable; it makes SQLRowCount always return 0 rows instead of -1. //retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_SCROLLABLE, 0); retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE, 0); It just needed a constant change from SQL_SCROLLABLE to SQL_NONSCROLLABLE. Looks like the intention was to make a proper driver, with forward and back scroll, but for some reason it was not completed. Now the problem propagates to Result.MoveNext and Result.Available. They loop forever, even when there's no more data to fetch. I made a further change in query_fill (removed a GB.Error that raised 'ODBC_NO_MORE_DATA' and added a return TRUE), but that did not get .MoveNext or .Available fixed: if((retcode2 == SQL_NO_DATA_FOUND) || (retcode2==SQL_NO_DATA)) { //GB.Error("ODBC_END_OF_DATA!"); //20150914 - zxMarce: Removed so .MoveNext and .Available work? return TRUE; //20150914 - zxMarce: Try to make .MoveNext fail when no more data } I think when we (you?) fix these problems, we will finally have a working Gambas ODBC subsystem. Thanks, *On 2015-08-27 15:06, Beno?t Minisini wrote:* > *Le 27/08/2015 20:03, Beno?t Minisini a ?crit :* >> *Le 27/08/2015 19:14, zxMarce a ?crit :* >>> Beno?t, >>> >>> No problem, I know you're not the author of the ODBC component. >>> Precisely, one of my modifications was adding an IF to call either >>> *SQLConnect* (normal method so far) or *SQLDriverConnect*; this is >>> the new call, and does not use .User, .Password nor .Name, as they >>> can all be set in the connection string. >>> I added, then, an IF and a FUNCTION. >>> This is the IF, in main.c's open_database: >>> ... And this is the function that new IF calls: >>> Thanks, >>> zxMarce. >> Please post directly to the developer mailing-list. nabble.com makes >> your mail unreadable by removing pictures. >> Or don't post pictures. Post the code as text! > If your function (is_host_a_connstring) returns a boolean value, you > can use 'bool' as return datatype. > If you are testing a boolean value, writing that: > if (xxx == TRUE) > is not needed. Just write: > if (xxx) > Regards, -- zxMarce. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hemanttannu at ...176... Tue Sep 15 05:53:29 2015 From: hemanttannu at ...176... (Hemant Mahajan) Date: Tue, 15 Sep 2015 09:23:29 +0530 Subject: [Gambas-devel] https for gambaswiki/bugtracker In-Reply-To: References: Message-ID: Hi I want to update photo in mysql database I am using Gambas 3.8.1 Please help me if you have any solution Regards (Hemant Mahajan) On Mon, Sep 14, 2015 at 3:18 PM, Ron wrote: > Benoit, > > You can request a free (for open-source projects) SSL certificate here: > https://www.globalsign.com/en/ssl/ssl-open-source/ > > You can extend it every year for free too. > > I have done the same for my site, and have a nice A+ rating. > Better to protect your users credentials. > > > Regards, > Ron_2nd. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Wed Sep 16 02:24:27 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Wed, 16 Sep 2015 02:24:27 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F6EABB.4050804@...176...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> Message-ID: <55F8B6BB.6070302@...1...> Le 14/09/2015 17:41, ML a ?crit : > Beno?t, > > Continuing here as you requested. > I found the problem in th driver that causes it to return 0 instead of > -1 in the RowCount. The offending line and my patch: > > //20150914 - zxMarce: Do NOT mark the STMT as Scrollable; it makes > SQLRowCount always return 0 rows instead of -1. > //retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, > SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_SCROLLABLE, 0); > retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, > SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE, 0); > > It just needed a constant change from SQL_SCROLLABLE to SQL_NONSCROLLABLE. > Looks like the intention was to make a proper driver, with forward and > back scroll, but for some reason it was not completed. > > Now the problem propagates to Result.MoveNext and Result.Available. They > loop forever, even when there's no more data to fetch. > I made a further change in query_fill (removed a GB.Error that raised > 'ODBC_NO_MORE_DATA' and added a return TRUE), but that did not get > .MoveNext or .Available fixed: > > if((retcode2 == SQL_NO_DATA_FOUND) || (retcode2==SQL_NO_DATA)) > { > //GB.Error("ODBC_END_OF_DATA!"); //20150914 - zxMarce: Removed so > .MoveNext and .Available work? > return TRUE; //20150914 - zxMarce: Try to make .MoveNext fail when > no more data > } > > I think when we (you?) fix these problems, we will finally have a > working Gambas ODBC subsystem. > > Thanks, > gb.db.odbc tells Gambas if he has a function to seek through a record at line 564 (with the no_seek connection flag). But having that function does not mean that for a specific ODBC driver, seeking is actually possible. In the query_fill() function at line 1152 you will see what the driver does: - If the seek function exist, then: - If the result has been marked scrollable successfully, then move to the specified position. - If the result is not scrollable, then move to the next record. - Otherwise, if the seek function does not exist, then move to the next record. If moving to the next record was not requested ('next' argument), then return TRUE (meaning an error). So, apparently, it's just Gambas that does not handle the no_seek connection flag at the moment. And we should force the query count to be -1 when seeking is not possible, whatever the reason (no seek function, or unscrollable query result). -- Beno?t Minisini From d4t4full at ...176... Wed Sep 16 16:36:19 2015 From: d4t4full at ...176... (ML) Date: Wed, 16 Sep 2015 11:36:19 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F8B6BB.6070302@...1...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> Message-ID: <55F97E63.5030603@...176...> *On 2015-09-15 21:24, Beno?t Minisini wrote:* > *Le 14/09/2015 17:41, ML a ?crit : * >> Beno?t, >> Continuing here as you requested. >> I found the problem in th driver that causes it to return 0 instead >> of -1 in the RowCount. The offending line and my patch: >> //20150914 - zxMarce: Do NOT mark the STMT as Scrollable; it makes >> SQLRowCount always return 0 rows instead of -1. >> //retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_SCROLLABLE, 0); >> retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE, 0); >> It just needed a constant change from SQL_SCROLLABLE to >> SQL_NONSCROLLABLE. >> Looks like the intention was to make a proper driver, with forward >> and back scroll, but for some reason it was not completed. >> Now the problem propagates to Result.MoveNext and Result.Available. >> They loop forever, even when there's no more data to fetch. >> I made a further change in query_fill (removed a GB.Error that raised >> 'ODBC_NO_MORE_DATA' and added a return TRUE), but that did not get >> .MoveNext or .Available fixed: >> if((retcode2 == SQL_NO_DATA_FOUND) || (retcode2==SQL_NO_DATA)) >> { >> //GB.Error("ODBC_END_OF_DATA!"); //20150914 - zxMarce: Removed >> so .MoveNext and .Available work? >> return TRUE; //20150914 - zxMarce: Try to make .MoveNext fail >> when no more data >> } >> I think when we (you?) fix these problems, we will finally have a >> working Gambas ODBC subsystem. >> Thanks, > gb.db.odbc tells Gambas if he has a function to seek through a record > at line 564 (with the no_seek connection flag). > But having that function does not mean that for a specific ODBC > driver, seeking is actually possible. > In the query_fill() function at line 1152 you will see what the driver > does: > - If the seek function exist, then: > - If the result has been marked scrollable successfully, then move > to the specified position. > - If the result is not scrollable, then move to the next record. > - Otherwise, if the seek function does not exist, then move to the > next record. If moving to the next record was not requested ('next' > argument), then return TRUE (meaning an error). > So, apparently, it's just Gambas that does not handle the no_seek > connection flag at the moment. > And we should force the query count to be -1 when seeking is not > possible, whatever the reason (no seek function, or unscrollable query > result). Beno?t, I've been investigating and came to the same conclusion you say regarding how the nested IFs work in query_fill. Unfortunately, making no_seek TRUE is not the answer (tried it), but setting the ODBC Statement Handle's SQL_ATTR_CURSOR_SCROLLABLE attribute to SQL_NONSCROLLABLE instead of SQL_SCROLLABLE makes the trick of returning -1 as rowcount. I don't like forcing flag values because they may come in handy for other purposes later. On the other hand, the ODBC Statement Handle is created once per Connection.Exec call, so I'm more comfortable with changing that. The problem that arises now is making Result.MoveNext (and preferably Result.Available also) work as it (they) should. Changing the SCROLLABLE to NONSCROLLABLE achieves, then, 2 things: 1- The rowcount returned is -1. 2- The Result object has data and is not Null (with a rowcount=0 the Result object raises a "Result is not available" error). Point 2 is what actually enables fetching data. The problem is now when all data has been retrieved: Result.Available is (still) TRUE and any subsequent Result.MoveNext raises an awful "ODBC_END_OF_DATA" error. This not only forces the programmer to resort to convoluted techniques to fetch the data, it will also make any data-aware control fail if they rely on .MoveNext and .Available working. What I did find, though, is that CResult.c is calling THIS->driver->Result.Fill and discarding the return value. Does not look wise, as the driver (at least gb.db.odbc) is actually returning whether the fill was or not successful. I added another three changes to CResult.c that fixed the problem and made Result.Available work, but Result.MoveNext still raises the error, although trappable by Try res.MoveNext() in Gambas: //20150916 zxMarce: Make .Available depend on the result of driver's query_fill bool myUnavailable = FALSE; //20150916 zxMarce: Make .Available depend on the result of driver's query_fill /* THIS->driver->Result.Fill(&THIS->conn->db, THIS->handle, pos, THIS->buffer, (pos > 0) && (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) ); */ myUnavailable = THIS->driver->Result.Fill(&THIS->conn->db, THIS->handle, pos, THIS->buffer, (pos > 0) && (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) ); //20150916 zxMarce: Make .Available depend on the result of driver's query_fill //THIS->available = TRUE; THIS->available = !myUnavailable; return FALSE; I now can fetch data without resorting to unnecessary error handling, although fixing the error risen by Result.MoveNext and making it return TRUE instead is still pending. I have to clean up the code a little bit and I think I can send it so you can check it. I don't know if the "myUnavailable" patch above will break other drivers' functionality, and have no other databases than MSSQL to test. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Wed Sep 16 17:19:57 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Wed, 16 Sep 2015 17:19:57 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F97E63.5030603@...176...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> Message-ID: <55F9889D.3080409@...1...> Le 16/09/2015 16:36, ML a ?crit : > *On 2015-09-15 21:24, Beno?t Minisini wrote:* >> *Le 14/09/2015 17:41, ML a ?crit : * >>> Beno?t, >>> Continuing here as you requested. >>> I found the problem in th driver that causes it to return 0 instead >>> of -1 in the RowCount. The offending line and my patch: >>> //20150914 - zxMarce: Do NOT mark the STMT as Scrollable; it makes >>> SQLRowCount always return 0 rows instead of -1. >>> //retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >>> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_SCROLLABLE, 0); >>> retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >>> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE, 0); >>> It just needed a constant change from SQL_SCROLLABLE to >>> SQL_NONSCROLLABLE. >>> Looks like the intention was to make a proper driver, with forward >>> and back scroll, but for some reason it was not completed. >>> Now the problem propagates to Result.MoveNext and Result.Available. >>> They loop forever, even when there's no more data to fetch. >>> I made a further change in query_fill (removed a GB.Error that raised >>> 'ODBC_NO_MORE_DATA' and added a return TRUE), but that did not get >>> .MoveNext or .Available fixed: >>> if((retcode2 == SQL_NO_DATA_FOUND) || (retcode2==SQL_NO_DATA)) >>> { >>> //GB.Error("ODBC_END_OF_DATA!"); //20150914 - zxMarce: Removed >>> so .MoveNext and .Available work? >>> return TRUE; //20150914 - zxMarce: Try to make .MoveNext fail >>> when no more data >>> } >>> I think when we (you?) fix these problems, we will finally have a >>> working Gambas ODBC subsystem. >>> Thanks, >> gb.db.odbc tells Gambas if he has a function to seek through a record >> at line 564 (with the no_seek connection flag). >> But having that function does not mean that for a specific ODBC >> driver, seeking is actually possible. >> In the query_fill() function at line 1152 you will see what the driver >> does: >> - If the seek function exist, then: >> - If the result has been marked scrollable successfully, then move >> to the specified position. >> - If the result is not scrollable, then move to the next record. >> - Otherwise, if the seek function does not exist, then move to the >> next record. If moving to the next record was not requested ('next' >> argument), then return TRUE (meaning an error). >> So, apparently, it's just Gambas that does not handle the no_seek >> connection flag at the moment. >> And we should force the query count to be -1 when seeking is not >> possible, whatever the reason (no seek function, or unscrollable query >> result). > > Beno?t, > > I've been investigating and came to the same conclusion you say > regarding how the nested IFs work in query_fill. > > Unfortunately, making no_seek TRUE is not the answer (tried it), but > setting the ODBC Statement Handle's SQL_ATTR_CURSOR_SCROLLABLE attribute > to SQL_NONSCROLLABLE instead of SQL_SCROLLABLE makes the trick of > returning -1 as rowcount. I don't like forcing flag values because they > may come in handy for other purposes later. On the other hand, the ODBC > Statement Handle is created once per Connection.Exec call, so I'm more > comfortable with changing that. > > The problem that arises now is making Result.MoveNext (and preferably > Result.Available also) work as it (they) should. > > Changing the SCROLLABLE to NONSCROLLABLE achieves, then, 2 things: > 1- The rowcount returned is -1. > 2- The Result object has data and is not Null (with a rowcount=0 the > Result object raises a "Result is not available" error). > > Point 2 is what actually enables fetching data. The problem is now when > all data has been retrieved: Result.Available is (still) TRUE and any > subsequent Result.MoveNext raises an awful "ODBC_END_OF_DATA" error. > This not only forces the programmer to resort to convoluted techniques > to fetch the data, it will also make any data-aware control fail if they > rely on .MoveNext and .Available working. > > What I did find, though, is that CResult.c is calling > THIS->driver->Result.Fill and discarding the return value. Does not look > wise, as the driver (at least gb.db.odbc) is actually returning whether > the fill was or not successful. > I added another three changes to CResult.c that fixed the problem and > made Result.Available work, but Result.MoveNext still raises the error, > although trappable by Try res.MoveNext() in Gambas: > > //20150916 zxMarce: Make .Available depend on the result of driver's > query_fill > bool myUnavailable = FALSE; > > //20150916 zxMarce: Make .Available depend on the result of driver's > query_fill > /* THIS->driver->Result.Fill(&THIS->conn->db, > THIS->handle, > pos, > THIS->buffer, > (pos > 0) && (pos == > (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) > ); */ > myUnavailable = THIS->driver->Result.Fill(&THIS->conn->db, > THIS->handle, > pos, > THIS->buffer, > (pos > 0) && > (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) > ); > > //20150916 zxMarce: Make .Available depend on the result of driver's > query_fill > //THIS->available = TRUE; > THIS->available = !myUnavailable; > return FALSE; > > I now can fetch data without resorting to unnecessary error handling, > although fixing the error risen by Result.MoveNext and making it return > TRUE instead is still pending. > I have to clean up the code a little bit and I think I can send it so > you can check it. > I don't know if the "myUnavailable" patch above will break other > drivers' functionality, and have no other databases than MSSQL to test. > If the ODBC driver can "scroll" its query result, we must use that. Why forcing the NONSCROLLABLE flag? As for the rest, I must first modify the gb.db component to add support for "move forward only" Result object, otherwise your patches are just hacks. I will tell you... Regards, -- Beno?t Minisini From d4t4full at ...176... Wed Sep 16 20:40:47 2015 From: d4t4full at ...176... (ML) Date: Wed, 16 Sep 2015 15:40:47 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F9889D.3080409@...1...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> Message-ID: <55F9B7AF.6070403@...176...> On 2015-09-16 12:19, Beno?t Minisini wrote: > Le 16/09/2015 16:36, ML a ?crit : >> On 2015-09-15 21:24, Beno?t Minisini wrote: >>> Le 14/09/2015 17:41, ML a ?crit : >>>> Beno?t, >>>> Continuing here as you requested. >>>> I found the problem in th driver that causes it to return 0 instead >>>> of -1 in the RowCount. The offending line and my patch: >>>> //20150914 - zxMarce: Do NOT mark the STMT as Scrollable; it >>>> makes SQLRowCount always return 0 rows instead of -1. >>>> //retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >>>> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_SCROLLABLE, 0); >>>> retcode = SQLSetStmtAttr(odbcres->odbcStatHandle, >>>> SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE, 0); >>>> It just needed a constant change from SQL_SCROLLABLE to >>>> SQL_NONSCROLLABLE. >>>> Looks like the intention was to make a proper driver, with forward >>>> and back scroll, but for some reason it was not completed. >>>> Now the problem propagates to Result.MoveNext and Result.Available. >>>> They loop forever, even when there's no more data to fetch. >>>> I made a further change in query_fill (removed a GB.Error that >>>> raised 'ODBC_NO_MORE_DATA' and added a return TRUE), but that did >>>> not get .MoveNext or .Available fixed: >>>> if((retcode2 == SQL_NO_DATA_FOUND) || (retcode2==SQL_NO_DATA)) >>>> { >>>> //GB.Error("ODBC_END_OF_DATA!"); //20150914 - zxMarce: Removed >>>> so .MoveNext and .Available work? >>>> return TRUE; //20150914 - zxMarce: Try to make .MoveNext fail >>>> when no more data >>>> } >>>> I think when we (you?) fix these problems, we will finally have a >>>> working Gambas ODBC subsystem. >>>> Thanks, >>>> >>> gb.db.odbc tells Gambas if he has a function to seek through a >>> record at line 564 (with the no_seek connection flag). >>> But having that function does not mean that for a specific ODBC >>> driver, seeking is actually possible. >>> In the query_fill() function at line 1152 you will see what the >>> driver does: >>> - If the seek function exist, then: >>> - If the result has been marked scrollable successfully, then >>> move to the specified position. >>> - If the result is not scrollable, then move to the next record. >>> - Otherwise, if the seek function does not exist, then move to the >>> next record. If moving to the next record was not requested ('next' >>> argument), then return TRUE (meaning an error). >>> So, apparently, it's just Gambas that does not handle the no_seek >>> connection flag at the moment. >>> And we should force the query count to be -1 when seeking is not >>> possible, whatever the reason (no seek function, or unscrollable >>> query result). >> Beno?t, >> I've been investigating and came to the same conclusion you say >> regarding how the nested IFs work in query_fill. >> Unfortunately, making no_seek TRUE is not the answer (tried it), but >> setting the ODBC Statement Handle's SQL_ATTR_CURSOR_SCROLLABLE >> attribute to SQL_NONSCROLLABLE instead of SQL_SCROLLABLE makes the >> trick of returning -1 as rowcount. I don't like forcing flag values >> because they may come in handy for other purposes later. On the other >> hand, the ODBC Statement Handle is created once per Connection.Exec >> call, so I'm more comfortable with changing that. >> The problem that arises now is making Result.MoveNext (and preferably >> Result.Available also) work as it (they) should. >> Changing the SCROLLABLE to NONSCROLLABLE achieves, then, 2 things: >> 1- The rowcount returned is -1. >> 2- The Result object has data and is not Null (with a rowcount=0 the >> Result object raises a "Result is not available" error). >> Point 2 is what actually enables fetching data. The problem is now >> when all data has been retrieved: Result.Available is (still) TRUE >> and any subsequent Result.MoveNext raises an awful "ODBC_END_OF_DATA" >> error. >> This not only forces the programmer to resort to convoluted >> techniques to fetch the data, it will also make any data-aware >> control fail if they rely on .MoveNext and .Available working. >> What I did find, though, is that CResult.c is calling >> THIS->driver->Result.Fill and discarding the return value. Does not >> look wise, as the driver (at least gb.db.odbc) is actually returning >> whether the fill was or not successful. >> I added another three changes to CResult.c that fixed the problem and >> made Result.Available work, but Result.MoveNext still raises the >> error, although trappable by Try res.MoveNext() in Gambas: >> //20150916 zxMarce: Make .Available depend on the result of >> driver's query_fill >> bool myUnavailable = FALSE; >> //20150916 zxMarce: Make .Available depend on the result of >> driver's query_fill >> /* THIS->driver->Result.Fill(&THIS->conn->db, >> THIS->handle, >> pos, >> THIS->buffer, >> (pos > 0) && (pos == >> (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) >> ); */ >> myUnavailable = THIS->driver->Result.Fill(&THIS->conn->db, >> THIS->handle, >> pos, >> THIS->buffer, >> (pos > 0) >> && (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) >> ); >> //20150916 zxMarce: Make .Available depend on the result of >> driver's query_fill >> //THIS->available = TRUE; >> THIS->available = !myUnavailable; >> return FALSE; >> >> I now can fetch data without resorting to unnecessary error handling, >> although fixing the error risen by Result.MoveNext and making it >> return TRUE instead is still pending. >> I have to clean up the code a little bit and I think I can send it so >> you can check it. I don't know if the "myUnavailable" patch above >> will break other drivers' functionality, and have no other databases >> than MSSQL to test. > > If the ODBC driver can "scroll" its query result, we must use that. > Why forcing the NONSCROLLABLE flag? > As for the rest, I must first modify the gb.db component to add > support for "move forward only" Result object, otherwise your patches > are just hacks. I will tell you... > Regards, Beno?t, Ok, I think I misunderstood your meaning (and maybe I still do!). If I can help in any way, just say the word. I just forced the attribute because it looked to me that at least MSSQL does not work with unixODBC correctly and I wanted to make the driver as general as possible. But, rereading your post, you say that it may be Gambas misbehaving, so I'll wait for you. In the meantime, I'll use what I already have because it works and I need it. I will not publish my changes other than here as I already did. Thanks, zxMarce. From gambas at ...1... Wed Sep 16 21:54:01 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Wed, 16 Sep 2015 21:54:01 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F9B7AF.6070403@...176...> References: <1440008445399-52283.post@...752...> <1440552179900-52451.post@...752...> <1440680055167-52511.post@...752...> <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> Message-ID: <55F9C8D9.4030809@...1...> Le 16/09/2015 20:40, ML a ?crit : > > Ok, I think I misunderstood your meaning (and maybe I still do!). If I > can help in any way, just say the word. > I just forced the attribute because it looked to me that at least MSSQL > does not work with unixODBC correctly and I wanted to make the driver as > general as possible. > > But, rereading your post, you say that it may be Gambas misbehaving, so > I'll wait for you. > In the meantime, I'll use what I already have because it works and I > need it. I will not publish my changes other than here as I already did. > > Thanks, > zxMarce. > Can you start playing with revision #7316? I have modified gb.db and gb.db.odbc so that the query_fill() method return: - DB_ERROR constant if query_fill() fails. - DB_OK constant if it succeeds. - DB_NO_DATA constant if we are moving forward and there is no row anymore. The query_init() must return -1 in its 'count' argument to indicate that the result is "forward only". Then 'gb.db' will raise an error if the user tries to use the Resule objet for something else that just forwarding one row by one row. Tell me what you can do with that. Regards, -- Beno?t Minisini From d4t4full at ...176... Mon Sep 21 15:08:42 2015 From: d4t4full at ...176... (zxMarce) Date: Mon, 21 Sep 2015 06:08:42 -0700 (MST) Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <55F9C8D9.4030809@...1...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> Message-ID: <1442840922852-53317.post@...752...> Beno?t, First off, with ODBC all .MoveXXX methods fail with "Result is forward only" as expected, except .MoveFirst() and .MoveNext(). That is OK. Second, I got the low level driver to return -1 as record count by specifying different "TDS_Version" values in the connection string. For example, "TDS_Version=7.2" returns zero, other versions return the expected -1 (4.2, 7, 7.1, 7.3, etc). This is also OK, because it is user-controllable. But now that I have tested your mods, I must report the bad news: Both .MoveNext and .Available properties always return FALSE, so there is no way to cleanly exit a data retrieval loop. I think the problem is in CResult.c at around line 145. That particular line calls the driver's query_fill function but disregards the return value, so the DB_ERROR, DB_OK and DB_NO_DATA return values are ignored. If it helps, I cooked this mod in CResult.c, which made it work as expected with ODBC, adjusting the return values of .MoveNext and .Available: //Next original line does not store the FILL call result, //therefore any call will be assumed OK even when the //ODBC driver says it failed. /*THIS->driver->Result.Fill(&THIS->conn->db, THIS->handle, pos, THIS->buffer, (pos > 0) && (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) );*/ //This next replacement line stores the FILL call result //in fillFailed so it can be checked later. int fillFailed = THIS->driver->Result.Fill(&THIS->conn->db, THIS->handle, pos, THIS->buffer, (pos > 0) && (pos == (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) ); //Next, check whether the FILL above succeeded or failed and //return proper states in Result.MoveNext and Result.Available. if (fillFailed) { THIS->available = FALSE; return TRUE; } Finally, if I misinterpreted your intentions (yet again), please disregard my suggestions. Regards, zxMarce. -- View this message in context: http://gambas.8142.n7.nabble.com/Change-to-gb-db-odbc-to-use-ODBC-Connection-Strings-tp52283p53317.html Sent from the gambas-devel mailing list archive at Nabble.com. From gambas at ...1... Thu Sep 24 02:23:26 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Thu, 24 Sep 2015 02:23:26 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <1442840922852-53317.post@...752...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> Message-ID: <5603427E.5090707@...1...> Is it better with revision #7334? Le 21/09/2015 15:08, zxMarce a ?crit : > Beno?t, > > First off, with ODBC all .MoveXXX methods fail with "Result is forward only" > as expected, except .MoveFirst() and .MoveNext(). That is OK. > > Second, I got the low level driver to return -1 as record count by > specifying different "TDS_Version" values in the connection string. For > example, "TDS_Version=7.2" returns zero, other versions return the expected > -1 (4.2, 7, 7.1, 7.3, etc). This is also OK, because it is > user-controllable. > > But now that I have tested your mods, I must report the bad news: Both > .MoveNext and .Available properties always return FALSE, so there is no way > to cleanly exit a data retrieval loop. > > I think the problem is in CResult.c at around line 145. That particular line > calls the driver's query_fill function but disregards the return value, so > the DB_ERROR, DB_OK and DB_NO_DATA return values are ignored. > > If it helps, I cooked this mod in CResult.c, which made it work as expected > with ODBC, adjusting the return values of .MoveNext and .Available: > > //Next original line does not store the FILL call result, > //therefore any call will be assumed OK even when the > //ODBC driver says it failed. > /*THIS->driver->Result.Fill(&THIS->conn->db, > THIS->handle, > pos, > THIS->buffer, > (pos > 0) && (pos == > (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) > );*/ > > //This next replacement line stores the FILL call result > //in fillFailed so it can be checked later. > int fillFailed = THIS->driver->Result.Fill(&THIS->conn->db, > THIS->handle, > pos, > THIS->buffer, > (pos > 0) && (pos == > (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) > ); > > //Next, check whether the FILL above succeeded or failed and > //return proper states in Result.MoveNext and Result.Available. > if (fillFailed) > { > THIS->available = FALSE; > return TRUE; > } > > Finally, if I misinterpreted your intentions (yet again), please disregard > my suggestions. > > Regards, > zxMarce. > -- Beno?t Minisini From d4t4full at ...176... Thu Sep 24 18:01:19 2015 From: d4t4full at ...176... (ML) Date: Thu, 24 Sep 2015 13:01:19 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <5603427E.5090707@...1...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> <5603427E.5090707@...1...> Message-ID: <56041E4F.8050806@...176...> Beno?t, Revision 7334 did the trick. It affects *.Available* and *.MoveNext* as desired/expected. Regards, zxMarce. On 2015-09-23 21:23, Beno?t Minisini wrote: > Is it better with revision #7334? > > Le 21/09/2015 15:08, zxMarce a ?crit : >> Beno?t, >> >> First off, with ODBC all .MoveXXX methods fail with "Result is forward only" >> as expected, except .MoveFirst() and .MoveNext(). That is OK. >> >> Second, I got the low level driver to return -1 as record count by >> specifying different "TDS_Version" values in the connection string. For >> example, "TDS_Version=7.2" returns zero, other versions return the expected >> -1 (4.2, 7, 7.1, 7.3, etc). This is also OK, because it is >> user-controllable. >> >> But now that I have tested your mods, I must report the bad news: Both >> .MoveNext and .Available properties always return FALSE, so there is no way >> to cleanly exit a data retrieval loop. >> >> I think the problem is in CResult.c at around line 145. That particular line >> calls the driver's query_fill function but disregards the return value, so >> the DB_ERROR, DB_OK and DB_NO_DATA return values are ignored. >> >> If it helps, I cooked this mod in CResult.c, which made it work as expected >> with ODBC, adjusting the return values of .MoveNext and .Available: >> >> //Next original line does not store the FILL call result, >> //therefore any call will be assumed OK even when the >> //ODBC driver says it failed. >> /*THIS->driver->Result.Fill(&THIS->conn->db, >> THIS->handle, >> pos, >> THIS->buffer, >> (pos > 0) && (pos == >> (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) >> );*/ >> >> //This next replacement line stores the FILL call result >> //in fillFailed so it can be checked later. >> int fillFailed = THIS->driver->Result.Fill(&THIS->conn->db, >> THIS->handle, >> pos, >> THIS->buffer, >> (pos > 0) && (pos == >> (DELETE_MAP_virtual_to_real(THIS->dmap, THIS->pos) + 1)) >> ); >> >> //Next, check whether the FILL above succeeded or failed and >> //return proper states in Result.MoveNext and Result.Available. >> if (fillFailed) >> { >> THIS->available = FALSE; >> return TRUE; >> } >> >> Finally, if I misinterpreted your intentions (yet again), please disregard >> my suggestions. >> >> Regards, >> zxMarce. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Thu Sep 24 18:05:53 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Thu, 24 Sep 2015 18:05:53 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <56041E4F.8050806@...176...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> <5603427E.5090707@...1...> <56041E4F.8050806@...176...> Message-ID: <56041F61.8040607@...1...> Le 24/09/2015 18:01, ML a ?crit : > Beno?t, > > Revision 7334 did the trick. > It affects *.Available* and *.MoveNext* as desired/expected. > > Regards, > zxMarce. > Actually you must use revision #7335, it fixes a bug in Result in creation mode. When you find gb.db.odbc good enough for you, tell me, and it will be put in Gambas 3.8.2. And if you want to continue to clean up the gb.db.odbc source code, don't hesitate, it's so badly written and indented in some places! Regards, -- Beno?t Minisini From d4t4full at ...176... Thu Sep 24 21:09:53 2015 From: d4t4full at ...176... (ML) Date: Thu, 24 Sep 2015 16:09:53 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <56041F61.8040607@...1...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> <5603427E.5090707@...1...> <56041E4F.8050806@...176...> <56041F61.8040607@...1...> Message-ID: <56044A81.6040203@...176...> Beno?t, Upgraded to 7335, it is still OK. I'll try DELETE, INSERT, etc now instead of just SELECT. For these commands, ODBC's SQLRowCount should return the actual row count, as documented. Regarding code formatting in ODBC's main.c, I concur, it's awful. On the plus side, it works! I don't know if it is that badly written (I doubt my C can make it better), but I can of course try to make it at least look nicer. Seems you respect my C more than I do! Regards, *On 2015-09-24 13:05, Beno?t Minisini wrote:* > Le 24/09/2015 18:01, ML a ?crit : >> Beno?t, >> Revision 7334 did the trick. >> It affects .Available and .MoveNext as desired/expected. >> Regards, >> zxMarce. > Actually you must use revision #7335, it fixes a bug in Result in > creation mode. > When you find gb.db.odbc good enough for you, tell me, and it will be > put in Gambas 3.8.2. > And if you want to continue to clean up the gb.db.odbc source code, > don't hesitate, it's so badly written and indented in some places! > Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From gambas at ...1... Thu Sep 24 21:14:33 2015 From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=) Date: Thu, 24 Sep 2015 21:14:33 +0200 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <56044A81.6040203@...176...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> <5603427E.5090707@...1...> <56041E4F.8050806@...176...> <56041F61.8040607@...1...> <56044A81.6040203@...176...> Message-ID: <56044B99.4060102@...1...> Le 24/09/2015 21:09, ML a ?crit : > Beno?t, > > Upgraded to 7335, it is still OK. > > I'll try DELETE, INSERT, etc now instead of just SELECT. > For these commands, ODBC's SQLRowCount should return the actual row > count, as documented. > > Regarding code formatting in ODBC's main.c, I concur, it's awful. On the > plus side, it works! > I don't know if it is that badly written (I doubt my C can make it > better), but I can of course try to make it at least look nicer. > Seems you respect my C more than I do! > > Regards, > I mainly thought about reindenting the code. By doing that, you will be able to understand the code better, and maybe you will find some strange things or useless code, as I did with query_fill(). A quick but important test is using the IDE database browser to connect to an ODBC databse, and see what happens, what crashes... If you can do that it would be cool. Regards, -- Beno?t Minisini From d4t4full at ...176... Fri Sep 25 12:22:24 2015 From: d4t4full at ...176... (ML) Date: Fri, 25 Sep 2015 07:22:24 -0300 Subject: [Gambas-devel] Change to gb.db.odbc to use ODBC Connection Strings. In-Reply-To: <56044B99.4060102@...1...> References: <55DF202B.1030807@...1...> <1440695666084-52536.post@...752...> <55DF5104.70804@...1...> <55DF51B8.6060706@...1...> <55F6EABB.4050804@...176...> <55F8B6BB.6070302@...1...> <55F97E63.5030603@...176...> <55F9889D.3080409@...1...> <55F9B7AF.6070403@...176...> <55F9C8D9.4030809@...1...> <1442840922852-53317.post@...752...> <5603427E.5090707@...1...> <56041E4F.8050806@...176...> <56041F61.8040607@...1...> <56044A81.6040203@...176...> <56044B99.4060102@...1...> Message-ID: <56052060.4040708@...176...> On 2015-09-24 16:14, Beno?t Minisini wrote: > Le 24/09/2015 21:09, ML a ?crit : >> Beno?t, >> Upgraded to 7335, it is still OK. >> I'll try DELETE, INSERT, etc now instead of just SELECT. For these >> commands, ODBC's SQLRowCount should return the actual row count, as >> documented. >> Regarding code formatting in ODBC's main.c, I concur, it's awful. On >> the plus side, it works! >> I don't know if it is that badly written (I doubt my C can make it >> better), but I can of course try to make it at least look nicer. >> Seems you respect my C more than I do! >> Regards, > I mainly thought about reindenting the code. By doing that, you will > be able to understand the code better, and maybe you will find some > strange things or useless code, as I did with query_fill(). > A quick but important test is using the IDE database browser to > connect to an ODBC databse, and see what happens, what crashes... If > you can do that it would be cool. > Regards, Beno?t, Ok, I'll review/realign the code in the Gambas ODBC driver and will submit the finished mess to you for inclusion. On the other hand, as I did in the past with VB6, I never used the DB facilities included in the IDE. I will try them, as well as a couple of the data-bound controls, and will report back to you. Regards, zxMarce.