[dba-issues] [Issue 102625] Table Data View + ODBC issues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 --- Additional comments from lu...@openoffice.org Fri Jan 14 08:33:51 + 2011 --- Did anything change from Dec 3? Or is this request just for msc? I did verify the "dba34c: #i102625# only fetch rows when the view moves outside the scope of the rowset window " changes and made my comments. There are indeed less "select * from y where key = ?". If you only scroll forward there are just a few when fetching the last page. That is an improvement. I'm not going to repeat my Dec 6 comments but the main issue is not the "select * from y where key = ?" but the initial "select * from y". Plus, the "select * from y where key = ?" still retrieves blob data while not used in table view. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 --- Additional comments from lu...@openoffice.org Mon Dec 6 10:22:08 + 2010 --- OK, I see where you are coming from. You need to refetch backward cursor positions since some drivers don't implement this correctly or lie about it. So your fix removed "unnecessary" refetching. As long as you scroll down, there should be no refetching. You looked at reducing the "select * from y where key = ?" I look at it from different perspective. I have a problem with the initial "select * from y". Why fetch the full table if you look at the table through a window (limited number of rows at a time)? Why load blobs or binary data when they are not displayed and when you can't do anything with them? No insert, no save. Opening large tables can be really slow (long time to first display) or simply impossible due to an out of memory condition (too many rows, blobs, ...). OOO internally is memorywise OK storing only the data for the window displayed but it forces the driver to fetch the whole lot... An overall minimum memory and bandwidth solution would consist of a "select key(s) from y" followed by a series of "select displayable fields from y where key(s) = ?". To further reduce bandwidth, replace the "where key(s) = ?" by "where key(s) = ? or key(s) = ? ... or key(s) = ?" to retrieve multiple rows in one go. MSAccess uses a fixed number of rows (10), but obviously a variable number (the rows needed to fill the window and not already displayed and not cached in OOO) would be optimal. I'm not going to reopen the issue again as it will be closed by the next reply but you will understand that for me the solution proposed only addresses a small and minor part of the problem (if there is no out of memory before displaying the first line...). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 User ludob changed the following: What|Old value |New value Status|RESOLVED |UNCONFIRMED Resolution|FIXED | --- Additional comments from lu...@openoffice.org Fri Dec 3 16:55:58 + 2010 --- I had a look at the changeset for "dba34c: #i102625# only fetch rows when the view moves outside the scope of the rowset window ". Apparently we are talking about different things... When opening a table in a table view, one or more SELECT * FROM table WHERE 1=0 is executed. Then a SELECT * FROM table. Then, to fill the form, a number of SELECT * from xx where key = ?. You addressed a problem with the last part while the problem reported is with the second part (the get the complete table). The complete table needs to be traversed to get the key values but there is no reason to get all the data from the table to use only the key values to re-get everything again one row at the time. I did some debugging: here is the stacktrace for the OPreparedStatement::executeQuery that does the select * from xx: odbcbasemi!connectivity::odbc::OPreparedStatement::executeQuery+0x94 [g:\ooo\dev300_m92\connectivity\source\drivers\odbcbase\opreparedstatement.cxx @ 293] dbami!dbaccess::OPreparedStatement::executeQuery+0xde [g:\ooo\dev300_m92\dbaccess\source\core\api\preparedstatement.cxx @ 227] dbami!dbaccess::ORowSet::impl_prepareAndExecute_throw+0x4ed [g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1681] dbami!dbaccess::ORowSet::execute_NoApprove_NoNewConn+0xe0 [g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1805] dbami!dbaccess::ORowSet::execute+0x17f [g:\ooo\dev300_m92\dbaccess\source\core\api\rowset.cxx @ 1588] frmmi!frm::ODatabaseForm::executeRowSet+0x35b [g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 1261] frmmi!frm::ODatabaseForm::load_impl+0x388 [g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 2919] frmmi!frm::ODatabaseForm::load+0x4f [g:\ooo\dev300_m92\forms\source\component\databaseform.cxx @ 2702] dbumi!dbaui::SbaXDataBrowserController::reloadForm+0xf7 [g:\ooo\dev300_m92\dbaccess\source\ui\browser\brwctrlr.cxx @ 733] dbumi!dbaui::SbaTableQueryBrowser::implLoadAnything+0x5ec [g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2333] dbumi!dbaui::SbaTableQueryBrowser::implSelect+0x1bfb [g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2612] dbumi!dbaui::SbaTableQueryBrowser::implSelect+0x92 [g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 2389] dbumi!dbaui::SbaTableQueryBrowser::impl_initialize+0x1e95 [g:\ooo\dev300_m92\dbaccess\source\ui\browser\unodatbr.cxx @ 3160] dbumi!dbaui::OGenericUnoController::initialize+0x51b [g:\ooo\dev300_m92\dbaccess\source\ui\browser\genericcontroller.cxx @ 408] dbumi!DBContentLoader::load+0x1949 [g:\ooo\dev300_m92\dbaccess\source\ui\browser\dbloader.cxx @ 320] fwkmi!framework::LoadEnv::impl_loadContent+0x4b8 fwkmi!framework::LoadEnv::startLoading+0x87 fwkmi!framework::LoadEnv::loadComponentFromURL+0x81 fwkmi!framework::Frame::loadComponentFromURL+0x94 dbumi!dbaui::DatabaseObjectView::doDispatch+0x7a4 [g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 164] dbumi!dbaui::DatabaseObjectView::doCreateView+0x86 [g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 119] dbumi!dbaui::DatabaseObjectView::openExisting+0x4b [g:\ooo\dev300_m92\dbaccess\source\ui\misc\databaseobjectview.cxx @ 106] dbumi!dbaui::OApplicationController::openElementWithArguments+0xefa [g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1926] dbumi!dbaui::OApplicationController::openElement+0x69 [g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1827] dbumi!dbaui::OApplicationController::onEntryDoubleClick+0xf7 [g:\ooo\dev300_m92\dbaccess\source\ui\app\appcontroller.cxx @ 1787] dbumi!dbaui::OAppDetailPageHelper::OnEntryDoubleClick+0x76 [g:\ooo\dev300_m92\dbaccess\source\ui\app\appdetailpagehelper.cxx @ 1060] dbumi!dbaui::OAppDetailPageHelper::LinkStubOnEntryDoubleClick+0xf [g:\ooo\dev300_m92\dbaccess\source\ui\app\appdetailpagehelper.cxx @ 1057] tlmi!Link::Call+0x11 dbumi!dbaui::DBTreeListBox::DoubleClickHdl+0x1c [g:\ooo\dev300_m92\dbaccess\source\ui\control\dbtreelistbox.cxx @ 468] svtmi!SvImpLBox::MouseButtonDown+0x18c >From what I can see, in ORowSet::execute_NoApprove_NoNewConn in dbaccess/source/core/api/RowSet.cxx, line 1809 impl_prepareAndExecute_throw() causes the "SELECT * from xx" using statementhandle 1, line 1830 m_pCache->setFetchSize(m_nFetchSize) and 1831 m_pCache->createIte
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Fri Nov 26 09:14:37 + 2010 --- OK. Fair enough. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Fri Nov 26 08:06:33 + 2010 --- I correctly understood that you were faking the length for boolean fields to 1. My point was that the code doesn't get to the case DataType::BIT: anymore for ADO sources. Therefor the length of the boolean doesn't matter anymore in copytablewizard. Output of SQLColumns using odbcte32 and MySQl Connector ODBC 5.1 for a table containing bit(1) , bit(5) and bit(31) fields: "TABLE_CAT", "TABLE_SCHEM", "TABLE_NAME", "COLUMN_NAME", "DATA_TYPE", "TYPE_NAME", "COLUMN_SIZE", "BUFFER_LENGTH", "DECIMAL_DIGITS", "NUM_PREC_RADIX", "NULLABLE", "REMARKS", "COLUMN_DEF", "SQL_DATA_TYPE", "SQL_DATETIME_SUB", "CHAR_OCTET_LENGTH", "ORDINAL_POSITION", "IS_NULLABLE" "test", , "bits", "id", 4, "integer", 10, 4, 0, 10, 1, "", , 4, , , 1, "YES" "test", , "bits", "bit1", -7, "bit", 1, 1, 0, 10, 0, "", , -7, , , 2, "NO" "test", , "bits", "bit5", -2, "bit", 1, 1, , , 0, "", , -2, , 1, 3, "NO" "test", , "bits", "bit31", -2, "bit", 4, 4, , , 0, "", , -2, , 4, 4, "NO" DATA_TYPE -7 = SQL_BIT and -2 = SQL_BINARY. I remember also having seen somewhere MySQL returning TINYINT for smaller bitfields (1http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Thu Nov 25 18:17:38 + 2010 --- Had a look at dba34b: #i115384# check if the length of BIT > 1 otherwise use setBoolean, and change typeinfo for ado types. Although I don't understand all changes I wanted to share a few comments: 1) ADOS::MapADOType2Jdbc doesn't produce any DataType::BIT anymore. adBoolean is translated to DataType::BOOLEAN. This alone would solve the original problem. The case DataType::BIT: in copytablewizard doesn't occur anymore when copying from ADO tables. 2) From your comments regarding Access reporting size 2 for adBoolean I fear that the number of bits and the byte representation gets mixed up. Access uses 2 bytes internally for a single Yes/No value. Hence, it reports size 2. It doesn't know multiple bit values. MySQL on the other hand knows multiple bit fields and will return up to 8 bytes to represent up to 64 bits. Using ODBC a MySQL BIT(1) and a BIT(5) field will return size 1, a BIT(31) field will return size 4, etc. However, only BIT(1) will return the SQL_BIT type (MySQl Connector ODBC 5.1). Multiple bit fields return SQL_BINARY. So, I don't know what database/interface source would cause a positive test BIT>1. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115398] copytablewizard: integer fields from MS Access are created autoincremen t or double in ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115398 --- Additional comments from lu...@openoffice.org Wed Nov 17 08:43:26 + 2010 --- No new problems encountered with bit fields since I applied the patch. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115398] copytablewizard: integer fields from MS Access are created autoincremen t or double in ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115398 --- Additional comments from lu...@openoffice.org Sat Nov 6 21:34:57 + 2010 --- The problem is caused by OFieldDescription::getSpecialTypeInfo(). For one reason or another, the bAutoIncrement field returns always true. I added the following line at line 631 in DEV300_m92\dbaccess\source\ui\tabledesign\FieldDescriptions.cxx pSpecialType->bAutoIncrement = IsAutoIncrement(); This returns the correct bAutoIncrement. But why doesn't m_pType contain the correct bAutoIncrement value? In OCopyTableWizard::loadData a call is made to OFieldDescription::FillFromTypeInfo but that doesn't modify m_pType. So I suspect the real solution to this problem is somewhere else. I'll do some further testing to see if nothing else is broken with this patch. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Sat Nov 6 14:34:03 + 2010 --- The problem is in dbaccess/source/ui/uno/copytablewizard.cxx. changeset 266756 moved "case DataType::BIT" in the function CopyTableWizard::impl_copyRows_throw. DataType::BIT now results in a call to aTransfer.transferComplexValue( &XRow::getBytes, &XParameters::setBytes ). getBytes tries to convert the VT_BOOL value to VT_ARRAY, which fails. Putting DataType::BIT back where it was, together with DataType::BOOLEAN, solves the problem in my copy of DEV300_m92. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115401] copytablewizard: currency fields from MS Access loose decimal places
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115401 --- Additional comments from lu...@openoffice.org Fri Nov 5 13:19:18 + 2010 --- I did some further investigation into what ADO reports as NUMERIC_PRECISION and NUMERIC_SCALE by writing a small c# program that retrieves and prints Connection.GetSchema(OleDbMetaDataCollectionNames.Columns) data for the test database attached. They are respectively 19 and 0 for currency fields. This is probably the reason why the wizard proposes 0 decimal places. But... NUMERIC_SCALE has apparently only a meaning for data types that have settable scales like the numeric and decimal types and not for fixed scale data types such as currency. Microsoft in its integration services (platform to convert other databases to SQLServer = copytablewizard from MS ;) ) defines currency scale as 4. See http://msdn.microsoft.com/en-us/library/ms141036.aspx, definition of DT_CY. At the bottom of that page, the JET currency data type is mapped to DT_CY... It isn't a coincidence that DT_CY has numeric value 6 which is the same as OleDbType.Currency or adCurrency... "Hard-wiring" the scale of currency to 4 seems to be the solution to this issue. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115398] copytablewizard: integer fields from MS Access are created autoincremen t or double in ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115398 --- Additional comments from lu...@openoffice.org Thu Nov 4 14:15:58 + 2010 --- The JDBC driver doesn't handle autoincrement fields at all. The field id in the test table provided should be autoincrement. This JDBC defect just masks the autoincrement issue. The internal database also works since it doesn't have autoincrement fields. We develop ODBC drivers... I'll leave the JDBC workaround comment for what it is. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115401] copytablewizard: currency fields from MS Access loose decimal places
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115401 User ludob changed the following: What|Old value |New value Status|CLOSED|UNCONFIRMED Resolution|INVALID | --- Additional comments from lu...@openoffice.org Thu Nov 4 13:27:44 + 2010 --- Of course you can change it manually for every currency field... But why would a wizard propose 0 decimals for a field that has always 4 decimal places? I hit this problem when transferring a 20+ table database... Together with issue 115398 which forces to change all integers, copying tables from access becomes very cumbersome. Manually tuning certain odd fields is acceptable, but modifying every integer and currency field isn't. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115401] copytablewizard: currency fields from MS Access loose decimal places
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115401 Issue #|115401 Summary|copytablewizard: currency fields from MS Access loose |decimal places Component|Database access Version|OOO330m13 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Thu Nov 4 10:34:22 + 2010 --- Copy MS Access table containing currency fields to ODBC databases or internal database. The destination table will be created with a NUMERIC (internal database, mssql, mysql) or DECIMAL (oracle 10) field type, which is fine, but with zero decimal places. The Access currency format is defined as having 4 decimal places. Test file attached. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115401] copytablewizard: currency fields from MS Access loose decimal places
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115401 --- Additional comments from lu...@openoffice.org Thu Nov 4 10:35:29 + 2010 --- Created an attachment (id=72853) MS Access table containing currency field - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115398] copytablewizard: integer fields from MS Access are created autoincremen t or double in ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115398 --- Additional comments from lu...@openoffice.org Thu Nov 4 10:14:48 + 2010 --- Created an attachment (id=72851) MS Access table with 2 integer fields, Autovalue on and off - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115398] copytablewizard: integer fields from MS Access are created autoincremen t or double in ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115398 Issue #|115398 Summary|copytablewizard: integer fields from MS Access are cre |ated autoincrement or double in ODBC Component|Database access Version|OOO330m13 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Thu Nov 4 10:13:00 + 2010 --- Copy a MS Access table containing integer fields to an ODBC connected database (tested with mysql, mssql driver). All integers are created as autoincrement (mysql) or identity (mssql) independent of the "AutoValue" field in the source. Mysql and mssql don't accept multiple autoincrement/identity fields in the same table. Mssql requires also a "SET IDENTITY_INSERT table ON" to insert identity fields. Using the oracle ODBC driver, integers are all converted to BINARY_DOUBLE (Oracle 10). Test file attached. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Thu Nov 4 07:23:33 + 2010 --- Original mdb's are too big to attach so I created a new one. 1 table containing an index and a boolean. I tried to copy the table to a new database (internal format) or an ODBC attached one: same error. Note that the table is created correctly in ODBC using a bit value (if the driver supports it). In the new database (internal format) it creates an integer field although the boolean field type exists. The error occurs when copying data. Since ODBC uses bit and internal uses integer, the conversion error is obviously in the ADO part. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 --- Additional comments from lu...@openoffice.org Thu Nov 4 07:25:31 + 2010 --- Created an attachment (id=72843) Access test file. 1 table with bit field - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 115384] copytablewizard: bit fiel ds fail in copy from MS Access
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=115384 Issue #|115384 Summary|copytablewizard: bit fields fail in copy from MS Acces |s Component|Database access Version|OOO330m13 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Wed Nov 3 19:15:19 + 2010 --- Copying an ms access table containing a bit field (field type Yes/No [bit]) with copytablewizard fails with an "S1000 The type could not be converted" error. This is a regression as it worked fine in versions 3.2.0 and 3.2.1. When copying to an ODBC destination, ODBC trace enabled, the error occurs just before binding the parameter for the INSERT statement. If the bitfield is fe. field #3, you will find BindParameter for fields #1 and #2 followed by SQLFreeStmt -> statement aborted. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102623] Character set conversion doesn't work correctly for field and table nam es using ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 --- Additional comments from lu...@openoffice.org Wed Mar 10 17:18:35 + 2010 --- I had a further look into this. Part of the problem is the windows ODBC manager. All drivers tested support wide character ODBC function calls (SQLExecuteW, etc) and the single byte character ones (SQLExecute, etc). The windows driver manager sits between OOO and the driver. OOO uses the single byte version of the ODBC function calls and the windows driver manager translates the single byte function calls to wide character ones. It translates also the parameters from system to utf16 in doing so (é in UTF8 is two bytes, translating with system to utf16 gives two wide characters). The drivers continue with the utf16 values and will use wrong field names. This explains the first 2 errors reported in the original issue. I have to conclude that this is not an OOO issue. The test case in my earlier comment today does however still show a problem with a double translation in OOO. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102623] Character set conversion doesn't work correctly for field and table nam es using ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 --- Additional comments from lu...@openoffice.org Wed Mar 10 16:53:30 + 2010 --- Tested on OOO320m12 and the problem is still there. Used the MyQL 5.1 driver and my own driver to test. Created a table named "test" with a field named "tést". Open table and insert row -> error: unknown column 'tÃf st' in field list. The odbc log shows a SQLPREPARE with the following query "INSERT INTO `test` (`ID`, `t\ff\ff\ff\ffst`) VALUES ...) . Clearly the é was translated twice with probably system->utf8 to become 4 bytes. According to the same log the table was created with the field name `t\ff\ffst` which is OK (windows ODBC manager doesn't know utf8 and logs all none ascii characters as \ff). - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=106422 User ludob changed the following: What|Old value |New value Status|RESOLVED |VERIFIED --- Additional comments from lu...@openoffice.org Tue Jan 12 17:32:25 + 2010 --- Yes, no problem. It's a pitty though that the 64bit implementation still uses 32 bit methods. This is going to bite back sooner or later. I'm not sure neither that when sequence and string lengths do move to 64 bit that somebody still remembers that some local variables (like nLen) in DBA are hardcoded to 32 bit. Personnally I would change them now to SQLLEN and then forget about it. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=106422
--- Additional comments from lu...@openoffice.org Wed Dec 16 10:06:59 +
2009 ---
OK
I noticed the changes for 64-bit ODBC (SQLINTEGER -> SQLLEN etc). Great, but...
OTools.cxx
OTools::bindData
219
case SQL_LONGVARBINARY:
{
sal_Int32 nLen = 0;
This should be sal_Int64 or better SQLLEN, shouldn't it?
Idem 226 case SQL_LONGVARCHAR:
Idem OTools:bindValue line 374 and 382
-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
-
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102791] ODBC binds NUMERIC and DE CIMAL statement parameters as CHAR
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102791 --- Additional comments from lu...@openoffice.org Wed Dec 16 08:59:03 + 2009 --- OK - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=106422 --- Additional comments from lu...@openoffice.org Tue Dec 15 11:35:01 + 2009 --- How can I get to dba33b? svn://svn.services.openoffice.org/ooo/cws only goes upto dba33a. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102791] ODBC binds NUMERIC and DE CIMAL statement parameters as CHAR
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102791 --- Additional comments from lu...@openoffice.org Thu Oct 29 15:05:03 + 2009 --- In the new function OPreparedStatement::setDecimal I left ::rtl::OString aString(::rtl::OUStringToOString(x,getOwnConnection()->getTextEncoding())); Text encoding shouldn't affect numbers. Not knowing if there are "side effects" I left it in there (copied OPreparedStatement::setString to create OPreparedStatement::setDecimal). If there are no side effects, please do leave it out. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102791] ODBC binds NUMERIC and DE CIMAL statement parameters as CHAR
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=102791
--- Additional comments from lu...@openoffice.org Thu Oct 29 14:58:17 +
2009 ---
OK. Here it goes (not a real diff):
connectivity/source/drivers/odbcbase/OTools.cxx @ 134
case SQL_CHAR:
case SQL_VARCHAR:
+ case SQL_DECIMAL:
if(_bUseWChar)
{
*pLen = SQL_NTS;
connectivity/source/drivers/odbcbase/OTools.cxx @ 160
break;
case SQL_NUMERIC:
- case SQL_DECIMAL:
if(_bUseWChar)
{
::rtl::OUString aString =
rtl::OUString::valueOf(*(double*)_pValue);
connectivity/source/drivers/odbcbase/OPreparedStatement.cxx @ 276
setParameter(parameterIndex,DataType::CHAR,aString.getLength(),(void*)&x);
}
+// -
+
+void SAL_CALL OPreparedStatement::setDecimal( sal_Int32 parameterIndex, const
::rtl::OUString& x ) throw(SQLException, RuntimeException)
+{
+ ::rtl::OString
aString(::rtl::OUStringToOString(x,getOwnConnection()->getTextEncoding()));
+
setParameter(parameterIndex,DataType::DECIMAL,aString.getLength(),(void*)&x);
+}
// -
Reference< XConnection > SAL_CALL OPreparedStatement::getConnection( )
throw(SQLException, RuntimeException)
{
connectivity/source/drivers/odbcbase/OPreparedStatement.cxx @ 530
setNull(parameterIndex,sqlType);
break;
case DataType::DECIMAL:
+{
+ORowSetValue aValue;
+aValue.fill(x);
+setDecimal(parameterIndex,aValue);
+}
+break;
case DataType::NUMERIC:
{
ORowSetValue aValue;
connectivity/source/inc/odbc/OPreparedStatement.hxx @ 146
virtual void SAL_CALL setString( sal_Int32
parameterIndex, const
::rtl::OUString& x ) throw(::com::sun::star::sdbc::SQLException,
::com::sun::star::uno::RuntimeException);
+ virtual void SAL_CALL setDecimal( sal_Int32
parameterIndex, const
::rtl::OUString& x ) throw(::com::sun::star::sdbc::SQLException,
::com::sun::star::uno::RuntimeException);
virtual void SAL_CALL setBytes( sal_Int32
parameterIndex, const
::com::sun::star::uno::Sequence< sal_Int8 >& x )
throw(::com::sun::star::sdbc::SQLException,
::com::sun::star::uno::RuntimeException);
These changes only affect DECIMAL and solves my issue with DB2. The binding of
DECIMAL is now identical to MSAccess. Therefor I would suspect MySQL ODBC to be
compatible with this change.
Regarding NUMERIC and DB2, although SQLGetTypeInfo reports NUMERIC as a
supported type for the IBM DB2 ODBC driver, I have never seen a NUMERIC type in
a reply to SQLColumns. All SQL NUMBER/DECIMAL fields are reported as DECIMAL.
The driver we have developped doesn't use NUMERIC at all for DB2. If this patch
works also with the other databases then NUMERIC can stay as it is.
-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
-
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=106422
--- Additional comments from lu...@openoffice.org Thu Oct 29 11:31:13 +
2009 ---
Your solution uses the original seq data but OPreparedStatement::setParameter
still allocates a buffer the size of your data which could be large. May I
suggest to change OPreparedStatement::setParameter to the following:
switch(fSqlType)
{
case SQL_CHAR:
case SQL_VARCHAR:
case SQL_DECIMAL:
case SQL_NUMERIC:
++nRealSize;
break;
+ case SQL_BINARY:
+ case SQL_VARBINARY:
+ nRealSize=1;//dummy buffer, binary data isn't copied
+ break;
default:
break;
}
-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
-
To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=106422 --- Additional comments from lu...@openoffice.org Thu Oct 29 10:28:51 + 2009 --- When trying to figure out a patch I encountered in OTools::bindData case SQL_VARBINARY this line // memcpy(_pData,pSeq->getConstArray(),pSeq->getLength()); just before the line that causes the problem _pData = (sal_Int8*)((const ::com::sun::star::uno::Sequence< sal_Int8 > *)_pValue)->getConstArray(); The commented line seems to me the solution to the problem. Why was it commented out?? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 106422] copytablewizard+ODBC cras hes on binary data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=106422 Issue #|106422 Summary|copytablewizard+ODBC crashes on binary data Component|Database access Version|OOO310m11 Platform|Unknown URL| OS/Version|Windows, all Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Thu Oct 29 09:41:38 + 2009 --- Copying binary data to an ODBC datasource using the table wizard crashes OOO. The problem is that the pointer to the binary data used in SQLBindParameter is invalidated before SQLExecute is called. Tested with MySQL Connector/ODBC 5.1 and own ODBC driver. I traced into OOO and found the following: In OPreparedStatement::setParameter, a new buffer is allocated for the data. In OTools::bindData, the pointer to this buffer is changed to point to the original data instead of copying the data to the buffer: case SQL_VARBINARY: ... _pData = (sal_Int8*)((const ::com::sun::star::uno::Sequence< sal_Int8 > *)_pValue)->getConstArray(); Compare this to case SQL_VARCHAR: memcpy(_pData,aString.getStr(),aString.getLength()); The original data is destroyed immediately after the call to OPreparedStatement::setBytes and, of course, _pData is invalidated as well... MySQL Connector doesn't capture the invalid pointer exception and crashes OOO hard. OOO not capturing exceptions bubbling up from drivers (dll's) is a real annoyance. OOO is simply removed from memory and all work since last save (autosave) is lost. No indication at all of the type of exception that occured. I'm not talking about SQL_ERROR type of exceptions (issue 52335) but about windows exceptions or dll runtime exceptions. If you want I'll create a new issue for this problem. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 101280] Report creation with ODBC source hangs application
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101280 --- Additional comments from lu...@openoffice.org Wed Jul 1 09:13:46 + 2009 --- I have no intention to hijack this bug. "Stop" should return to user control. When your PC has been churning 5 hours on a 400 MB table I guess you run out of physical memory and start swapping. Even if OOO sends an SQLCancel to the driver while doing the select * from table, which I couldn't verify, and the driver does cancel the operation correctly, I would expect that cleaning up the resultset in the driver and OOO would take also a lot of time because of swapping and cause a long delay to regain user control. Shouldn't take hours though. Could you check memory usage before and after stop? After you push stop, is OOO consuming CPU or is it idling? Some ODBC drivers are reported to have problems with SQLCancel not doing anything.(mysql 3.51, oracle 9.2.0.7.0 with oracle server on NT, DB2 client 7.?, ...). This would also cause ooo to hang around not releasing user control. What driver are you using? Issue 66846 reports OOO crashing on out of memory conditions opening large tables. JDBC apparently reports an out of heap memory condition. Not sure what your odbc driver is doing: stop and report or just sit there. If getting 1MB of data out of a 400MB database isn't possible because of "just the wrong way about things", I for sure call that a bug. Even a show stopper. I'm considering raising priority on issue 102625 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 101280] Report creation with ODBC source hangs application
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101280 --- Additional comments from lu...@openoffice.org Wed Jun 24 11:37:31 + 2009 --- In issue 102625 I explained in detail that in order to get the key values from the table, OOO executes a "select * from table". It then gets the fields needed by a "select fields from table where id=?" for every row needed. So, not only is OOO getting every record twice from the db but also ,if for example you need only 4 decimal columns out of 95 columns, ooo still retrieves all the columns in the first query wasting sometimes an enormuous amount of memory. My suggested fix was to do a "select id from table" followed by the "select fields from table where id=?" queries to retrieve individual rows. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 101280] Report creation with ODBC source hangs application
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101280 User ludob changed the following: What|Old value |New value CC|'mechtilde' |'ludob,mechtilde' --- Additional comments from lu...@openoffice.org Wed Jun 24 09:14:42 + 2009 --- The select * from table is also in OOO310m11 and not related to SRB. When accessing data from a table, view table or report or..., the select * is executed. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102791] ODBC binds NUMERIC and DE CIMAL statement parameters as CHAR
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102791 --- Additional comments from lu...@openoffice.org Wed Jun 24 09:05:01 + 2009 --- Numeric is a little more complex but for Decimal I agree that data should be transferred as a string, but, for the driver to know what to do with it, the ParameterType value in SQLBindParameter should be set to SQL_DECIMAL, the ValueType being set to SQL_C_CHAR or SQL_C_WCHAR. This is also how MsAccess binds Decimal parameters. At least for Decimal, this solution should solve the problem for all DB's. For Numeric, I haven't tested yet. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 66846] Out of memory when opening large tables
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=66846 User ludob changed the following: What|Old value |New value CC|'pmike' |'ludob,pmike' --- Additional comments from lu...@openoffice.org Fri Jun 19 06:29:10 + 2009 --- Last week I reported issue 102625. A select * from table is sent to the database to get just the key values when using ODBC. Seems JDBC has the same problem. OOO310m11 has also this problem. Looking into the OOO source code all this seems to happen in dbaccess/source/core/api which is the part NOT depending on the connectivity (ODBC,JDBC,mysql,) - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 --- Additional comments from lu...@openoffice.org Fri Jun 19 06:22:50 + 2009 --- Same as Issue 66846? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 --- Additional comments from lu...@openoffice.org Thu Jun 18 14:29:48 + 2009 --- Same as issue 101280? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 101280] Report creation with ODBC source hangs application
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101280 --- Additional comments from lu...@openoffice.org Thu Jun 18 13:06:14 + 2009 --- Looks like OOO is reading here also the whole table just to get the key values as reported in issue 102625. When you look at the memory usage you will probably see that OOO is eating up al your memory. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102791] ODBC binds NUMERIC and DE CIMAL statement parameters as CHAR
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102791 Issue #|102791 Summary|ODBC binds NUMERIC and DECIMAL statement parameters as | CHAR Component|Database access Version|OOO310m11 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Mon Jun 15 12:16:58 + 2009 --- ODBC binds NUMERIC and DECIMAL statement parameters as CHAR. As a result the values are quoted as any other string. This is fine for databases such as Oracle and MySQL that cast automatically a string to numeric or decimal. DB2 however does not allow a string to decimal assignment. Updating or inserting decimal values is not working and throws the database error SQLSTATE=42821 SQLCODE=-408. OPreparedStatement::setObjectWithInfo() forces DataType::DECIMAL and DataType::NUMERIC to bind as a string (setString(parameterIndex,aValue);). I suppose this was not done by accident. What is the reason for this? OTools::getBindTypes does generate the correct bindtypes for DataType::DECIMAL and DataType::NUMERIC but they are not used. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 --- Additional comments from lu...@openoffice.org Sun Jun 14 08:09:38 + 2009 --- Same as issue 98548 ?? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 98548] Memory leak when opening t ables in non-native-datbases
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=98548 --- Additional comments from lu...@openoffice.org Sun Jun 14 08:07:09 + 2009 --- Last week I issued 102625 (Table Data View + ODBC issues select * from table to get only key data). By the looks of it, this is the same issue. OOO retrieves unnecessarily the full table to get only the key values. The impact on the machines memory depends on the table structure (f.e.large blobs in the table) and indeed on the odbc driver and database client used. This is not an OOO memory leak however. Memory is released when the resultset is closed, unless the ODBC driver or database client leak memory... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102623] Character set conversion doesn't work correctly for field and table nam es using ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 --- Additional comments from lu...@openoffice.org Wed Jun 10 18:41:48 + 2009 --- same behavior in OOO310m11 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102623] Character set conversion doesn't work correctly for field and table nam es using ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 --- Additional comments from lu...@openoffice.org Wed Jun 10 08:28:28 + 2009 --- same behavior in OOO310m11 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 User ludob changed the following: What|Old value |New value Summary|Table Data View + ODBC iss|Table Data View + ODBC iss |ues select * from table to|ues select * from table to | get only key data| get only key data --- Additional comments from lu...@openoffice.org Wed Jun 10 08:27:43 + 2009 --- same behavior in OOO310m11 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102625] Table Data View + ODBC is sues select * from table to get only key data
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102625 Issue #|102625 Summary|Table Data View + ODBC issues select * from table to g |et only key data Component|Database access Version|OOO300m9 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Tue Jun 9 17:40:48 + 2009 --- Opening a table for viewing issues a few "select * from table where 0=1" to get the table metadata. One should be fine but, unless the underlying database has a long "ping" (over the net), the extra traffic is not problematic. What is a big problem is the "select * from table" followed by as many "select * from table where id='?'" statements as there are lines to display. The first select * is used to get only the primary key or other index. A "select id[,id2,...] from table" should do if one does only a SQLGetData on the key field(s). Or..., since you have the select *, use the data that you just retrieved and forget about the select * where id=?. But not both. Imagine the extra traffic when the table contains blobs: they are not displayed in the Table view and are retrieved from the database twice... Things get even worse when the ODBC driver, for one reason or another, gets all the data into the client's memory when SQLExecute is called on the select * for a large table. Here is how ms access is doing it: "Select id from table" followed by a series of "select field1,field2,... from table where id=? or id=? or [total of 10 ids] or id=?" to get ten rows at a time. The select where 0=1 is done when you create the link, which is OK for how ms access uses linked tables but is in my opinion a minus for ms access. Blobs, Clobs, memos, etc are only retrieved, using a separate select, when the field is visible in the view. Time to first screen and scrolling speed is much faster than for OOO. Overall, the way how OOO handles ODBC databases and what you can do with them is great compared to ms Access. Larger tables, especially on networked databases, can however be a show stopper. Replacing the select * by a select ids should already be a big improvement. Ludo Brands - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 102623] Character set conversion doesn't work correctly for field and table nam es using ODBC
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=102623 Issue #|102623 Summary|Character set conversion doesn't work correctly for fi |eld and table names using ODBC Component|Database access Version|OOO300m9 Platform|PC URL| OS/Version|Windows XP Status|UNCONFIRMED Status whiteboard| Keywords| Resolution| Issue type|DEFECT Priority|P3 Subcomponent|none Assigned to|dbaneedsconfirm Reported by|ludob --- Additional comments from lu...@openoffice.org Tue Jun 9 16:22:17 + 2009 --- When selecting in Database properties / Additional settings / Data conversion / Character Set the value Unicode(utf8), field and columns names are not displayed or used correctly everywhere when non ascii characters are present in the names. The errors: - column headers in the Table Data View are not correctly displayed. Non ascii characters are replaced with a "white question mark in black square" or other symbol. The fields listed when editing the table structure are correct however. Table was created using originale database client software (Oracle web client, Mysql Query Browser,...) - create a new table in design view with field names containing non-ascii characters. The Table Data View will display the field name correctly but when looking at the database with the database vendor's tools, the field name was created with every non ascii character replaced by 2 other characters. The fields listed when editing the table structure correspond with what is seen on the database. - create a new table with a table name containing non-ascii characters. The table will be created with wrong characters in it's name. This behavior is noticed with ODBC drivers from Oracle and MySQL. I'm also developping a special ODBC driver and I've noticed that for example in case 2, the driver will receive a call to SQLExecDirectW with a wide string "Create table ..." containing in the field name the characters é instead of the expected character é. Since é is the byte representation of é in UTF8, I have to conclude that the UTF8 code is encoded by a single byte codepage (system?) to unicode conversion. When I looked at the character codes sent and received in the other test cases, the conclusion was similar: a wrong encoding/decoding is used: probably system-unicode instead of utf8-unicode. Same problem is noticed in 2.4.1. Ludo Brands - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
