Which account register?  Is it the only one you have open?

When you say "enter [a new transaction]", do you mean "input parts of" or the GnuCash-specific Transaction Enter operation, a-la <menu:Transaction/Enter Transaction> or the Enter key on the keyboard?

Do these steps work for you on a new/empty datafile — perhaps after running the New  Account Hierarchy Setup druid through to completion with default values?

This issue manifests itself in different accounts (eg: checking, credit card, etc) but I always have a single register open at once - never more than one.

By "enter" I mean recording a new transaction.  I've typically entered date, description, transfer account, amount and hit enter - this is when the error appears.

I have not tried this on a new datafile as this is my production work.

(In reply to comment #2)
> I have not tried this on a new datafile as this is my production work.

You can create a different datafile without affecting your "production work".  They're just datafiles.  Just don't save the empty file over your production file.

Confirming that I was seeing this bug in 2.0.5 and now more frequently now that I upgraded to 2.2.1.

I have not yet tried to create a new data file; I have several entities that I manage and so far I think I am only seeing it in the most complicated one (12 current asset accounts, numerous -- more than 50 -- expense accounts, 4 credit card liability accounts, one mortgage liability account, more than ten scheduled transactions). I don't recall ever seeing the problem in a simpler data file. The complicated one was originally imported from a Quicken QIF into GnuCash 1.8.x and has been in constant use.

I will attempt to discern a pattern that makes the error happen, but so far I have not.

SO FAR it only seems to happen when I am entering a series of transactions and am entering a transaction to the same payee as a previous transaction (not necessarily from the same session). When the error is about to occur, the information does NOT get auto-filled from the earlier transaction, and I see the "transaction being edited in another register" message when I attempt to close the transaction. Most of transactions I enter contain some sort of split, but I don't believe the error is more or less likely to occur with a split transaction.

Because the register is not auto-filling, I have not been able to tell whether the error is because of the current transaction or a non-closed previous transaction. Closing the register and re-opening it seems to "fix" the problem, though I must start the entry again from scratch.

Oh and for more information -- I'm running Ubuntu Feisty 7.04 but I backported and installed 2.1.1 from Gutsy 7.10 using the prevu utility. I was running GnuCash 2.0.5 in the Ubuntu Backports repository for Feisty 7.04.

It occurs to me that not only do I have relatively few accounts in my other GnuCash data files, I'm also fairly unlikely to enter more than one or two transactions at a time in those. SO as I get a chance I will create representative "empty" data files and see if I can cause the error to occur.

Update -- I just had the problem occur on the second action after opening GnuCash. I was reconciling a bank statement and had entered the interest payment, then when I started to enter the first missing transaction into the account register, I saw the behavior -- it was the same as a previous transaction but wasn't being autofilled, etc.

I closed the register and reopened it, and then the register behaved normally.

I am experimenting now to see if the behavior improves when I DON'T have lots of register tabs open when I start and use GnuCash. (Normally for this account I have more tabs open than can fit in the window.)

At this point, I periodically still experience the problem.  It manifests itself in precisely the same manner that Tommy describes.  I generally only have 1 account open at one time, so I do not believe this has anything to do with the number of accounts open.

Likewise, it only presents itself when entering a transaction that is a duplicate of a previous one and gnucash should retreive it from the account history.  I have not seen this occur on new transactions (unduplicated payee).

This continues to happen frequently to me -- at least a few times per session. Usually running 2.2.1 on Windows XP, but it also occurs under Linux. I haven't been able to discern any pattern to it, but it definitely slows down entering data. I rarely have more than three or four tabs open.

Also, might this be related to bug #393383?

Still get this problem frequently in 2.2.3 under WinXP. It's quite frustrating.

Continues to occur at least a couple of times in almost every gnucash session for 2.2.4 under WinXP. After entering a transaction, I can't record it, so I have to cancel, switch to another register, switch back, and do it again.

Getting this more frequently lately -- sometimes every single transaction (that matches an old transaction) gives this error, and I have to retry four or five times before I can actually enter the new transaction. Can be 30-40 times per session. Is it possible am I the only one consistently affected by this bug? Any suggestions on what I could try to avoid it? Even switching back to another register doesn't always work now. It's really making gnucash almost unusable. 

Like Adam, I consistently experience this problem.  I don't see it on every transaction, but it occurs at least once during every session.  

I have committed r17623 in trunk which will not get rid of the message box but at least may allow you to finish entering the transaction. (The fact that the message box appears is still a bug.)

Also note that this bug is very similar to bug 393383. In fact, it was that bug that got me started on a fix.

I'm so happy to hear about some possible progress on this bug. Does anyone have a Windows build with r17623? The Cyberbird site seems to be down and my own attempts to build under Windows have not proven successful.

I have just committed r17628, which prevents the message box from appearing. In combination with r17623, this fixes this bug and bug 393383.

I'm not sure when these changes will get backported though, as changes to register code is particularly danger prone. So these changes may need to sit in trunk for a while until is seems likely that nothing else is mistakenly broken.

Re comment 15: The only version of GnuCash that includes the updated code is "trunk", which is not considered stable code. It could be dangerous to use with your data. However if there were a Windows build available for that code, would you be willing to give it a test drive?

Sure, I would test drive a Windows build. I'm a (mostly dormant) Debian developer, so I'm not afraid of unstable code. I'm not sure why it's been so difficult to build gnucash myself (I have all the prereqs installed), but if you could provide an executable for Windows I would try it on a copy of my data.

Is there a chance past data will actually be corrupted, or is the more likely scenario that the program just crashes without saving latest entries?

I think basically anything goes if you use trunk. Who knows what will happen. Trunk works fine in my testing, but I only use a small portion of the functionality and I don't exercise it thoroughly. Honestly I think it is unlikely to destroy any data, but who knows? By definition it is the bleeding edge.

At least if you try it for a few days then you can confirm that the patches fix your bug. The patch works for me but it would be better to have you test it since you seem to get the problem a lot. (I was only able to reproduce it by using the procedure shown in bug 393383.)

I will inquire on the developer's list about building a Windows copy from trunk for testing purposes.

When I inquired about a building a Windows version from trunk, it turned out that trunk still wasn't compiling for Windows due to some aqbanking-related things. Before it was fixed, my Windows PC died, so you may have to inquire on the mailing list or build a copy yourself. Sorry.

Unfortunately, sh.exe always segfaults on me when I try to build using the instructions on the wiki. I'd love to be able to build this myself but have never had any luck.

Hmm, I had that at first, too. This worked for me:

http://www.mingw.org/wiki/Environment_issues

Yes, I've been pursuing support on the msys email list. Everyone recommends the Logitech fix first -- but this machine does not have a Logitech QuickCam and has never had one.

Is this bug fixed in 2.2.8? I'm still trying to build from source. I was never able to troubleshoot the msys issues--we tracked it down to an msys.dll function returning null that wasn't supposed to (and isn't tested for an unexpected return value):

http://www.nabble.com/Re%3A-Msys-sh-stackdump-during-make-td20744591i20.html

I'm also trying to cross-compile from linux, but that isn't working either. The builder gets stuck on gmp, which it can't seem to cross compile. It's unfortunate that it is so hard to build this package.

No, this isn't fixed in 2.2.8 and I didn't expect that it would be, as I think I'm the only one that has tried it out, and register fixes need more scrutiny than other fixes before being released. I only wish that I had been able to compile trunk for you before my PC died. As I'm now on a Mac, maybe you could write to the developer's mailing list and ask someone to compile it for you? Otherwise, I don't know how we get this fix tested, as you seem to be one of the few people that can reproduce it.

As the original poster, I routinely experience this problem when entering transactions.  I'm more than willing to try some new code if available.

I wouldn't claim this bug is reproducable in that I cannot consistently make it occur.  But, it does occur on a regular basis.  For example, when entering approx 40 transactions last night, it occurred at least 3-4 times.

Unfortunately no takers on the gnucash dev list to provide a win32 svn build.

The msys/mingw folks finally found the bug that was causing the build to fail. I was finally able to build gnc win32 svn, although there were several bad URLs and switches in the installation script that needed to be fixed for it to build. (Does anyone actually maintain this stuff?) So now I have a fully built gnc win32 from svn; unfortunately, it crashes (or otherwise dies) without displaying any error shortly after the splash screen and "tip of the day." So I still can't test this fix. I'm open to any suggestions.

Adam, typically it seems that Andreas makes changes to the Windows installer scripts. I would ask about this and about the crash on the mailing list where everyone can see the problem and suggest an answer. Include the contents of your gnucash.trace file if that looks at all interesting. (Look in /c/tmp, I think.)

"without displaying any error shortly": 
(In reply to comment #28)
> gnc win32 from svn; unfortunately, it crashes (or otherwise dies) without
> displaying any error shortly after the splash screen and "tip of the day." So I
> still can't test this fix. I'm open to any suggestions.
> 

Maybe you'll have to to turn on console output explicitly by
defining the exetype, see
http://wiki.gnucash.org/wiki/Windows#Console_output_and_exetype

I've been working with a recent build since I finally solved all the mingw/msys problems plus the gnucash build problems. The problem ("That transaction is already being edited in another register. Please finish editing it there first") is greatly reduced but unfortunately *not* gone entirely. In one session today, I had the error message appear three times. It seems to be confined to instances where the description for the transaction being entered matches an earlier description and the user hits "tab" to complete the match. But the problem is still there.

This is svn r17803.

(As a side note, this svn build seems much faster/more responsive on win32!)

I'm glad the problem has at least been reduced. Maybe I missed a case somewhere.

Are you now able to at least complete the entry after the message pops up? Or do you still have to start over?

Also, on occasions where the message pops up, did hitting "Tab" on the description appear to "work", i.e. did it bring in more than just the description from the earlier transaction, such as the account? Or does it just fill in the description only?

My recollection is that "tab" copied the description but not the account. But I will need to replicate to answer your question properly -- since the bug is rarer now it's not as easy to diagnose. I will report back more specifically next time it occurs.

I just got the error even without any description matching. The only way out to entire a new transaction was to close the register entirely and reopen it. In that session, it several times in a short time span.

Wow, I could never seem to make that happen. So there wasn't even an auto-fill involved?

Perhaps you could run gnucash with the --log command line option. That might show some interesting (and long) results when the problem occurs. One thing I did in trunk while adding register changes was to add some new debugging code too. This should cause your gnucash.trace file to contain a lot of debugging messages which will hopefully be useful.

gnucash --log gnc.ledger=debug

Correct, no auto-fill involved in this most recent instance. I will add the log option to my normal start; should I just email you the log? I assume it will contain some personal info, so I don't want to post publicly.

I should mention that I also get this problem occasionally under Debian (using the same account file), although most of my usage is in win32.

I don't think it will have personal info, but you can just email it to me if you believe it does.

Okay, I sent Charles some trace files.

Thanks, Adam. There was one example in the files you sent me, and that has helped a lot. I now suspect that this bug is unrelated to bug 393383, though the symptoms are similar.

I see from the trace files that you went to enter a transaction. You navigated through the date, num, and description fields, then moved to the transfer field. No auto-completion occurred. Then the transaction saving routine (gnc_split_register_save) gets called for some reason, and at that point the transaction is open (as expected), but there is no blank split. The register therefore concludes that it is an existing transaction being edited (as opposed to a brand new one.) Since it is already open but not marked as pending in this particular register, it then concludes that it must be pending in another register. Therefore the warning displays.

If I have all that correct, then the root of the problem seems to be that the blank split of the new transaction being entered (and there always should be one) has been lost at some point, or was never there in the first place. I suspect that was already the situation when departing the description field, because auto-completion should have worked unless there was no blank split (since auto-completion is not supposed to occur except on brand new transactions.)

Note that I refer to "blank split" above as a concept that exists in the code itself, not a visual element seen by users.

Adam, I take it that you are using the register in Basic Ledger mode (as evidenced by a "transfer" field.) If you switch to Transaction Journal mode, does the problem still occur?

Also, to further investigate, I'll need to add more debugging messages to the code. If I provide a patch, can you rebuild GnuCash and produce a new trace file?  It may be several days before I can get to this though.

 I've made the debugging changes and emailed a patch to Adam.

I rarely use anything other than Basic Ledger mode, and I don't recall any specific instances where this bug occurred in Transactional Journal mode. I will try that and report back.

I will apply the patch and give you a new trace next time this occurs.

It's odd that you only found one instance of this issue in the trace files I sent you -- there were definitely several instances in those sessions. Was it just that you only found one, or there is only one in the whole trace?

Just a random thought (knowing very little about how the code actually works), but does gnc_split_register_save get called when there is an automatic timed save of the entire data file?

Just got the bug in Transaction Journal mode.

A few more data points that may or may not help:

- We suspected maybe auto-save was implicated. But I've completely disabled auto-save and get the same behavior.

- Sometimes when I get the error, there *should* be a register match based on the description, but there isn't.

- It seems to go in phases -- sometimes I keep closing and reopening the register and getting the error; then at some point it just works for a while without a glitch.

I've shared some more trace files with the extra debugging data with Charles. Hopefully we'll get to the bottom of this.

As best I can tell, Charles' latest patch that I'm testing has eliminate this problem entirely. The patch simply uncomments the call to gnc_split_register_redraw on line 1677 of src/gnome/gnc-split-reg.c. I leave it to Charles to explain in more detail, but apparently I was hitting enter after starting a new (empty) transaction and that caused the entry to lock before any data was entered. Uncommenting gnc_split_register_redraw eliminates that problem, and I don't believe I've found any other ways to reproduce the behavior after that. (There was an earlier patch from Charles I've also applied; not sure if that fix was also involved).

Is it possible to get a linux build with this bug fix (or instructions/patch to apply)?  I'm currently running 2.2.4 built from r16997 on 2008-03-27 on Ubuntu 8.04 with kernel 2.6.24-23-generic

It was just a one-line change to src/gnome/gnc-split-reg.c -- just uncomment the call to gnc_split_register_redraw() inside gnc_split_reg_record() which is around line 1680 in trunk. The change appears safe enough (just adds a redraw), but obviously this is just experimental and unreleased at this point. In fact I think it could be just a workaround to a real bug somewhere else. I'm still working through the code to what I can find.

By the way... the simplest workaround is to just avoid hitting Enter on a blank transaction.

FYI - I've never encountered this bug by hitting Enter on a blank transaction.

Yeah, I'm not 100% convinced that hitting enter was always the cause for me, but I was able to reproduce the lock by hitting enter after starting a blank transaction and then attempting to enter the data. Whether there were other causes or not, the uncommenting fix mentioned above seems to have gotten rid of what was once a ubiquitous problem for me.

Re comment 49:

So far as I can tell, this code change only runs when you hit Enter or press the Enter button in the toolbar. You don't think you might accidentally (or subconciously) hit Enter twice to finish off a new transaction entry? Or double-click that toolbar button? Because that would be one Enter for the new entry and one Enter for the new blank one.

However, it could be that there are other ways to reproduce the problem and we just haven't discovered them yet. The problem seems to be gone for Adam -- perhaps you could try the code change and see if it works for you. If it doesn't, then I guess we'll still have a mystery to solve.

Here's how the bug manifests itself for me, everytime.

I begin typing a transaction.  When I enter the description, gnucash attempts to find a previous transaction with same info and copy it.  In this case, if their is a previous transaction that gnucash should copy and the description does appear but the transfer and amount do NOT appear, I *know* the bug has occurred and will not allow me to finish the transaction.  Conversely, if the transfer and amount do appear, life is fine.

That matches what we are seeing. Say you successfully save a new transaction and now you're on an empty new line, ready to enter another new transaction. If you accidentally hit Enter before anything else, GnuCash gives no visual indication that anything has happened. But it puts itself into a state where now it thinks that you are editing an existing transaction rather than entering a brand new one. Therefore auto-completion will not succeed, because auto-completion is only for brand new transactions.

Give it a try and see if you can reproduce what we're seeing.

Yes, I can reproduce that scenario.

Well that's the only way that Adam and I could predictably reproduce the problem. In any case, Adam says the suggested change described in comment 47 has prevented the problem from reappearing. If you can compile GnuCash from source, could you try that out?

I've just committed r17894 into SVN trunk, which I believe fixes the bug without adding an extra redraw as a workaround. Adam or Jeff, could you try it out?

I've been playing around for a while now with r17925 and have not encountered this bug. It seems fixed for me.

Fixed in trunk in r17894, but unlikely to be backported for 2.2. Marking as fixed with a target version of  2.3.x.

*** Bug 586896 has been marked as a duplicate of this bug. ***

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=426111. Please update any external references or bookmarks.