Problem description: When adding a new record to a subform that is connected to access data base via odbc Libre Office crashes and restarts Steps to reproduce: 1. Open form add data then try to save 2. .... 3. .... Current behavior: Libre Office crash Expected behavior: Add new record and move to next new record. Operating System: Windows 8 Version: 4.0.0.2 rc Last worked in: 3.6.5.2 rc
Can you attach a very simple access database for us to test this?
Created attachment 73930 [details] One mdb file and one odb file connect to each other via mysql-odbc to test bug Please note that the files I am uploading are connected to each other using the Access connection type, the bug happened while I was connected to the same data using mysql-odbc driver, this driver is much more efficient with large volumes of data. I did not test for the bug using any other driver than the mysql-odbc driver. As stated originally the crash happens when adding data to the sub form "call Report" inside the form named "Murdock Call Report".
To confirm issue I reverted back to 3.6.5.2 rc and the forms worked again as they should.
Created attachment 73934 [details] reproduction example with MS Access https://www.dropbox.com/s/61sko683omymw52/Issue%20Bug%2060022.zip Okay I am a bit new to this, and am not sure why my files were turned to text. I have added a link to a hosted zip file that should be downloadable. Thank you to all for your patience with me. I hope I have not broken any rules.
Lionel - can you check this one out?
Comment on attachment 73934 [details] reproduction example with MS Access changing mime type of attachment
hm, so far I cannot reproduce. Please correct me if I'm wrong: Windows XP LibreOffice RC 2 1) Download zipped stuff 2) unzip 3) Open odb file with database 4) Click on "forms" 5) open first form, call report spreadsheet 6) enter random data in last row 7) Save Result: No crash... have you tried resetting your profile?
Created attachment 74070 [details] screenshot - new entries I am not able to confirm this so far although I am not so familiar with Database; however I was able to enter some new rows without a crash. Could you give some specific step by step instructions as to how to replicate? I tested on W8 Pro 32bit Libreoffice Version 4.0.0.2 .0.2 (Build ID: 5991f37846fc3763493029c4958b57282c2597e. I have attached a screen show of new entries. Thanks.
(In reply to comment #2) > > Please note that the files I am uploading are connected to each other using > the Access connection type, the bug happened while I was connected to the > same data using mysql-odbc driver, this driver is much more efficient with > large volumes of data. I did not test for the bug using any other driver > than the mysql-odbc driver. As stated originally the crash happens when > adding data to the sub form "call Report" inside the form named "Murdock > Call Report". Hi Ken, OK I relooked at this and carefully reread your comment #2 :) It's been a long while since I worked with databases so you'll have to bear with me. As you said the data is connected with Access connection type. If change this to MySQL-obdc (right click Murdock Call Report, Database, Connection Type..) and then select name of obdc data source as dbase files, character set = system, I get an error - "data could not be loaded. There exists no table named "Customer List" Can you give me some very clear instructions so that we can replicate with the database you have uploaded? Thanks.
Ken, since you have the problem with MySQL/ODBC, it would be useful if you provided a dump of the affected MySQL database. This would allow me to try to reproduce the problem more easily, since getting to a MS Windows machine is harder for me than a MySQL server. Also (just in the case it makes a difference, sometimes it does): - MySQL ODBC connector version - MySQL server version Thanks in advance. Alternatively, if you get the problem with Embedded HSQL, too, that's also a good reproduction case to attach: QA people/testers have *nothing* extra to install/configure to reproduce the problem. Thanks in advance.
All thank you for your continued efforts. You will need to work from a windows machine in order to reproduce this issue. I do not have a Linux box to test. In order to connect to the data using MySQL-odbc you will have to register the database from this executable if you have a 64 bit system. C:\Windows\SysWOW64\odbcad32.exe If you have a 32 bit system simply execute the odbc data sources from control panel then register the data source, I do not think the name is critical as long as you point toward the correct data. I chose to register my databases as an odbc source because they are much faster with large data sets and several new releases of Libre would have a bug in the native access connector and it normally would take several updates before it was fixed. It is still very important to maintain the native connector though please don’t drop support for it. When opening the form please remember the error/crash occurs when adding data to the center sub-form. I was testing with the latest version of 4.0, yes it was RC2. When I reverted back to the latest 3.5 release candidate everything worked great again. *From:* bugzilla-daemon@freedesktop.org *Sent:* February 2, 2013 5:57 AM *To:* kcoe11@gmail.com *Subject:* [Bug 60022] EDITING: Sub form data entry causes crash headsup <u982t5hg5498@outlook.com> changed bug 60022<https://bugs.freedesktop.org/show_bug.cgi?id=60022> What Removed Added Status UNCONFIRMED NEEDINFO Ever confirmed 1 *Comment # 9 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c9> on bug 60022 <https://bugs.freedesktop.org/show_bug.cgi?id=60022> from headsup<u982t5hg5498@outlook.com> * (In reply to comment #2 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c2>)> > Please note that the files I am uploading are connected to each other using > the Access connection type, the bug happened while I was connected to the > same data using mysql-odbc driver, this driver is much more efficient with > large volumes of data. I did not test for the bug using any other driver > than the mysql-odbc driver. As stated originally the crash happens when > adding data to the sub form "call Report" inside the form named "Murdock > Call Report". Hi Ken, OK I relooked at this and carefully reread your comment #2 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c2> :) It's been a long while since I worked with databases so you'll have to bear with me. As you said the data is connected with Access connection type. If change this to MySQL-obdc (right click Murdock Call Report, Database, Connection Type..) and then select name of obdc data source as dbase files, character set = system, I get an error - "data could not be loaded. There exists no table named "Customer List" Can you give me some very clear instructions so that we can replicate with the database you have uploaded? Thanks. ------------------------------ You are receiving this mail because: - You reported the bug.
(In reply to comment #11) > You will need to work from a windows machine in order > to reproduce this issue. I do not have a Linux box > to test. I do have a GNU/Linux box. I would like to test from GNU/Linux to see if this bug is specific to MS Windows or also happens on other OS. Please attach a dump of the MySQL database with which you have the issue. > In order to connect to the data using MySQL-odbc you will have to > register the database (...) Yes, but even from Windows, before connecting to the data using "MySQL-ODBC", we will need to import the database into a MySQL server. Please attach a dump of the MySQL database with which you have the issue.
There is not a mysql database. I used the mysql-odbc connection to attach to the access database file I supplied. I am sorry if I have somehow caused confusion. I have provided links to a series of screen captures that should clear it up. Of note look closely at the odbc admin capture. Hope this helps and thank you again. https://www.dropbox.com/s/fy4uuy6xi4rndp5/Capture%20Data%20base%20source.JPG https://www.dropbox.com/s/252ydoqcblu5dhs/Capture%20Database%20property.JPG https://www.dropbox.com/s/jgckyp151ybetx7/Capture%20ODB%20screen%20capture%20note%20source%20at%20bottom.JPG https://www.dropbox.com/s/4gkq7s2ygd9wb8w/Capture%20ODBC%20admin.JPG On Sat, Feb 2, 2013 at 12:38 PM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 12 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c12>on bug > 60022 <https://bugs.freedesktop.org/show_bug.cgi?id=60022> from Lionel > Elie Mamane <lionel@mamane.lu> * > > (In reply to comment #11 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c11>) > > > You will need to work from a windows machine in order > > to reproduce this issue. I do not have a Linux box > > to test. > > > I do have a GNU/Linux box. I would like to test from GNU/Linux to see if this > bug is specific to MS Windows or also happens on other OS. Please attach a dump > of the MySQL database with which you have the issue. > > In order to connect to the data using MySQL-odbc you will have to > > register the database (...) > > Yes, but even from Windows, before connecting to the data using "MySQL-ODBC", > we will need to import the database into a MySQL server. Please attach a dump > of the MySQL database with which you have the issue. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
(In reply to comment #13) > There is not a mysql database. I used the mysql-odbc connection to attach > to the access database file I supplied. I understand now. Thank you for the clarification. You used "MySQL (ODBC)" for the "Database type" setting in LibreOffice, but then gave it an ODBC DSN that uses a non-MySQL driver. When using a non-MySQL ODBC driver, the intention is that one uses "ODBC" for the "Database type" setting. The "MySQL (ODBC)" setting sets a couple of other settings internally meant for the MySQL ODBC driver and that may or may not work well with other ODBC drivers. (With "ODBC", one can set or unset these settings manually in "Advanced Settings"). Ken, since you attached a reproduction example with "native" (actually under the hood, ADO) "MS Access" for "Database type" setting, could you please confirm whether you get the bug with "MS Acces" for "Database type", too, or not? Since you said you tested only with ODBC... Thanks in advance for this information. Ken, could you please proof-check my instructions below and correct them if they need to be? Thanks. Headsup, since you tested with "MS Access" for "Database type", could you please test with "ODBC", as per instructions below? Thanks. If some QA person can reproduce and give me backtrace from a debug version, that would be *very* useful. Here are detailed instructions: Download attachment 73934 [details]. Unzip, e.g. to c:\some\path On a 64 bit OS, use C:\Windows\SysWOW64\odbcad32.exe; on a 32-bit OS, use C:\Windows\system\odbcad32.exe (or is it "system32" instead of "system"?). Go to "User DSN" tab, click "Add..." button. Choose the "Microsoft Access Driver (*.mdb)", and point it to c:\some\path\the file you created by unzipping.mdb. Name the DSN "Call Report 2". Open c:\some\path\the file you created by unzipping.odb (in LibreOffice) Menu Edit / Database / Connection Type. Choose "ODBC", Next. Browse, select "Call Report 2", OK. Finish. In the main window, Database pane (left), click on "Forms". In the "forms" pane (lower right), double-click on "Murdock Call Report". A new window opens. In the grid area where one of the columns is "Comments on Call", go to bottom (empty line), enter some data, go again to the new empty line. You have just added new data. If you don't get a crash, report it here. If you get a crash, report it here and if possible attach a backtrace from a debugger.
Okay your directions are spot on. I have tested two connections now and the direct connect using Access connection type will allow adding of data. When the connection type is changed to MySql ODBC a crash occurs. If I perform the same test using any 3.5 or 3.6.5.2 version all works perfect. I have included a couple links to two videos one depicting the crash and the other shows how much slower the table draws under version 4.0.. Please note I have a master file with more than 30K records and it draws instantly using ODBC but very slowly if I use the Access connection type. I also have included some crash information screen shots. After I uninstall 4.0 and install 3.6 everything works great again. Hope it helps. Link to slow draw https://www.dropbox.com/s/fi8ggojbl6uqvjt/20130203_1903_22%20Very%20Slow%20drawing.avi Link to crash video https://www.dropbox.com/s/wepve99xazpk4dv/20130203_1915_22%20Crash%20During%20Data%20entry.avi Link to error capture https://www.dropbox.com/s/fy4uuy6xi4rndp5/Capture%20Data%20base%20source.JPG https://www.dropbox.com/s/252ydoqcblu5dhs/Capture%20Database%20property.JPG https://www.dropbox.com/s/ei10oktvka8qa1h/Capture%20Information%20error.JPG https://www.dropbox.com/s/mblr29s2vtgqyar/Capture%20SQL%20Status%20.JPG https://www.dropbox.com/s/m4gpxoiumbcubib/Capture%20Data%20could%20not%20be%20loaded.JPG Link to entire folder content https://www.dropbox.com/sh/mr2yg9kjh2s8ga2/kFFZTy5y8C On Sun, Feb 3, 2013 at 4:36 AM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 14 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c14>on bug > 60022 <https://bugs.freedesktop.org/show_bug.cgi?id=60022> from Lionel > Elie Mamane <lionel@mamane.lu> * > > (In reply to comment #13 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c13>) > > There is not a mysql database. I used the mysql-odbc connection to attach > > to the access database file I supplied. > > > I understand now. Thank you for the clarification. You used "MySQL (ODBC)" for > the "Database type" setting in LibreOffice, but then gave it an ODBC DSN that > uses a non-MySQL driver. When using a non-MySQL ODBC driver, the intention is > that one uses "ODBC" for the "Database type" setting. The "MySQL (ODBC)" > setting sets a couple of other settings internally meant for the MySQL ODBC > driver and that may or may not work well with other ODBC drivers. (With "ODBC", > one can set or unset these settings manually in "Advanced Settings"). > > Ken, since you attached a reproduction example with "native" (actually under > the hood, ADO) "MS Access" for "Database type" setting, could you please > confirm whether you get the bug with "MS Acces" for "Database type", too, or > not? Since you said you tested only with ODBC... Thanks in advance for this > information. > > Ken, could you please proof-check my instructions below and correct them if > they need to be? Thanks. > > Headsup, since you tested with "MS Access" for "Database type", could you > please test with "ODBC", as per instructions below? Thanks. > > If some QA person can reproduce and give me backtrace from a debug version, > that would be *very* useful. Here are detailed instructions: > > Download attachment 73934 [details] <https://bugs.freedesktop.org/attachment.cgi?id=73934> [details] <https://bugs.freedesktop.org/attachment.cgi?id=73934&action=edit>. > > Unzip, e.g. to c:\some\path > > On a 64 bit OS, use C:\Windows\SysWOW64\odbcad32.exe; on a 32-bit OS, use > C:\Windows\system\odbcad32.exe (or is it "system32" instead of "system"?). Go > to "User DSN" tab, click "Add..." button. Choose the "Microsoft Access Driver > (*.mdb)", and point it to c:\some\path\the file you created by unzipping.mdb. > Name the DSN "Call Report 2". > > Open c:\some\path\the file you created by unzipping.odb (in LibreOffice) > > Menu Edit / Database / Connection Type. > > Choose "ODBC", Next. > > Browse, select "Call Report 2", OK. > > Finish. > > In the main window, Database pane (left), click on "Forms". > > In the "forms" pane (lower right), double-click on "Murdock Call Report". > > A new window opens. In the grid area where one of the columns is "Comments on > Call", go to bottom (empty line), enter some data, go again to the new empty > line. You have just added new data. If you don't get a crash, report it here. > If you get a crash, report it here and if possible attach a backtrace from a > debugger. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
(In reply to comment #15) > I also have included some crash information screen shots. (...) > Link to error capture > https://www.dropbox.com/s/fy4uuy6xi4rndp5/Capture%20Data%20base%20source.JPG > https://www.dropbox.com/s/252ydoqcblu5dhs/Capture%20Database%20property.JPG > https://www.dropbox.com/s/ei10oktvka8qa1h/Capture%20Information%20error.JPG > https://www.dropbox.com/s/mblr29s2vtgqyar/Capture%20SQL%20Status%20.JPG > https://www.dropbox.com/s/m4gpxoiumbcubib/Capture%20Data%20could%20not%20be%20loaded.JPG I'm confused. In what conditions do you get this error message? I thought this bug report was about a *crash* without error message, and that's what your video shows.
You are correct. I was testing as many scenarios as possible. The error screens were taken after I changed the connection from MySql ODBC to just "ODBC". They may have no bearing on the issue at all. I was trying to find any clue that might help but inadvertently caused confusion. Good catch. FYI after I uninstalled the latest 4 RC then I re-installed the latest 3.6 RC and am using the same profile as I have been using for years. All is working perfect. The video were taken using the MySql ODBC connection. If there is a dump or error log somewhere just point me to it and I will be happy to post it. On Sun, Feb 3, 2013 at 11:27 PM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 16 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c16>on bug > 60022 <https://bugs.freedesktop.org/show_bug.cgi?id=60022> from Lionel > Elie Mamane <lionel@mamane.lu> * > > (In reply to comment #15 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c15>)> I also have included some crash information screen shots. (...) > > Link to error capture > > https://www.dropbox.com/s/fy4uuy6xi4rndp5/Capture%20Data%20base%20source.JPG > > > https://www.dropbox.com/s/252ydoqcblu5dhs/Capture%20Database%20property.JPG > > https://www.dropbox.com/s/ei10oktvka8qa1h/Capture%20Information%20error.JPG > > https://www.dropbox.com/s/mblr29s2vtgqyar/Capture%20SQL%20Status%20.JPG > > https://www.dropbox.com/s/m4gpxoiumbcubib/Capture%20Data%20could%20not%20be%20loaded.JPG > > > I'm confused. In what conditions do you get this error message? I thought this > bug report was about a *crash* without error message, and that's what your > video shows. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
(In reply to comment #17) > I was testing as many scenarios as possible. Great, thanks for that. > The error screens were taken after I changed the connection > from MySql ODBC to just "ODBC". As I said, this is recommended when using a non-MySQL ODBC data source. Just to be clear, this error message appears when inserting new data in the subform? Try with just "ODBC" and (in advanced settings of the database) check the box next to "replace named parameters by ?". Does it make a difference, or same error message.
Confirmation: Crash occurs only during data entry in sub forms whether amending or adding a new record. I cannot test your last request. Must catch a plane will be in and out rest of day. Sent from Windows Mail *From:* bugzilla-daemon@freedesktop.org *Sent:* February 4, 2013 8:21 AM *To:* kcoe11@gmail.com *Subject:* [Bug 60022] EDITING: Sub form data entry causes crash *Comment # 18 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c18> on bug 60022 <https://bugs.freedesktop.org/show_bug.cgi?id=60022> from Lionel Elie Mamane <lionel@mamane.lu> * (In reply to comment #17 <https://bugs.freedesktop.org/show_bug.cgi?id=60022#c17>)> I was testing as many scenarios as possible. Great, thanks for that. > The error screens were taken after I changed the connection > from MySql ODBC to just "ODBC". As I said, this is recommended when using a non-MySQL ODBC data source. Just to be clear, this error message appears when inserting new data in the subform? Try with just "ODBC" and (in advanced settings of the database) check the box next to "replace named parameters by ?". Does it make a difference, or same error message. ------------------------------ You are receiving this mail because: - You reported the bug.
Any news on this? Ken, could you please try with just "ODBC" and (in advanced settings of the database) check the box next to "replace named parameters by ?". Does it make a difference, or same error message? Also, there are many things tried here, some give a crash, other error messages, etc. Could you please summarise for us which does what, with exact reproduction instructions? I mean e.g. instead of "add data to subform", something like: - LibreOffice version 4.0.3.2 on Microsoft Windows version ZZZZ, .odb file contained in attachment XXXX to this bug, connecting with "Access" driver (connection type) to the .mdb in attachment YYYY to this bug. - In Edit / Database / Properties, correct the path to the .mdb file to where you put it. - Open form blahblah - Navigate to record ID=5 - In the textbox for field "Foo" (which belongs to a subform), which is now blank, enter "Jolly Jumper" - This should insert a row in table "Bar", but crashes instead. - Same test with connection type "ODBC", these and these settings in edit / database / advanced, with ODBC driver version XXXXX - Error message, but no crash. For error messages, please show/copy *each* error message in the pile. In the error message box, click "more", then in the left pane of the dialog, click each entry in turn and show what's in the right pane for each of these.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO