Recently Used is missing

[ambulantpony]

Have just found out that using sql-ledger [tekki 3.2.12.39] on an sql-ledger-3.2.12 dataset will ask to update that dataset. Run it, takes a few seconds then goes to the login page. Things start out fine (dark.css has some artifacts but is otherwise lovely), but if I run a date range of transactions, click on the reference number to open one, it barfs, complaining about RU.pm.

It looks like I don't have a "recent" table. Probably some other stuff missing too. Well, no, I don't, and neither does my SL-3.2.12 install over on Production. I ran it all again to the same conclusion. Was thinking the 'update dataset' work would notice the missing table and build it but it looks like it doesn't.

There's an .sql file that appears to update the recent table but I can't find something to actually build it. It might be mentioned there but I'm perl ignorant. If you can point out a blah.sql to run, I'll run it.

Just wanted to take a look around to see what options are out there, if any, for S-L.

thanks

[Tekki]

What is the error message you get? What kind of installation do you have here? Don't to try to explain the error, just describe what you are doing and what happens.

[Tekki]

There was an error in the migration from an original database that I could reproduce. If you install the most recent code from Github, it should be solved.
Please notice that you need some more Perl modules for this version, especially Excel::Writer::XLSX (Debian package libexcel-writer-xlsx-perl) for the spreadsheets.

[ambulantpony]

Sorry for not picking up the correct reply-to addy. Thank you for the quick reply, quick isn't necessary at this end. In short, I tried 2.3.12.039 and nothing has changed. Here is the error when I click a reference number to open seemingly any transaction: Reports > Chart of Accounts [select one] > Enter a date range > click a reference # > Boom:

…

------------------------------------------------- DBD::Pg::db do failed: ERROR: relation "recent" does not exist LINE 1: UPDATE recent SET id = nextval('recentid') ^ at SL/RU.pm line 172. Error! UPDATE recent SET id = nextval('recentid') WHERE (employee_id = ? AND object_id = ?) ERROR: relation "recent" does not exist LINE 1: UPDATE recent SET id = nextval('recentid') ^ A repeat login repeats the notice that data will be updated, appears to run something but nothing changes in behavior.

------------------------------------------------- This is on a remote bare metal server, Intel Ice Lake Xeon, 128GB, running OmniOS-r151046 (LTS release) Postgresql-16.2 Installed package Apache-2.4.58 Installed package DBI-1.643 compiled from CPAN source DBD-Pg-3.15.0 Compiled from CPAN source mod_perl-2.0.11 Compiled from CPAN source That's "all". OmniOS is not a bloated Linux distro; it has the perl it needs plus a bit but what "you" need is up to you to install, you're the Admin after all. Quite a bit like Slackware back in the day. I untarred Tekki-Version and symlinked it to sql-ledger. Also copied in the current users directory. Dataset is owned by Pg user that is called by the S-L-t user logged in. Rather than using S-L-t natively perhaps I should untar it on top of a functional S-L in the same manner S-L does updates to itself. I had been running the latest DBD-Pg-3.18 and mod_perl-2.0.13. That worked fine too but I have also been trying, off and on, to isolate a problem where documents that were attached to a new transaction sometimes became unattached. (I don't link to a stored document, I directly write-in a document to the archivedata table where perl breaks it up into blocks and writes them out. It's like the issue is something where attaching forgets to update the reference table pointing to what archive_id is being asked for. What I need to try is to attach a document then get a row count from archivedata. Then run a re-index (to try and lose the attachment) and then another row count. That might tell me if data is actually not being written or if it is but the pointer in reference is broken, and a re-attach just writes over the original rows, as it they weren't there, so it appears to be a new attach. That's why the attach dialog pops up rather than an error.) There was a time where this never happened. I have had a dozen or more pages of, say, a contract, scanned and attached and updated before finally hitting Post and it would zip through all of them at once brrrrr and that was it. No issue at all. I sent an email to Dieter about this and was gently informed that "it works fine." :^) This appeared quite a while back so Test had been running 3.2.9 to see how things were there. 3.2.8 was blocked because the was a data format change and S-L doesn't undo format changes, it's ever onward for current data. There was an issue with Postgresql and index corruption in, I think, 15.<something>, and I ...might... be able to precipitate the problem now by re-indexing the 'Reference' table. But 16 is quicker and the recent 16.2 has a lot of fixes and mitigated nasties so I'm not likely to roll that back; the plan is just not to re-index any table. Data is on mirrored SSDs and my load is tiny by Postgresql's standards. I've also played with cache sizes in case a re-index is touching only data already written to disk and not first forcing data in-cache to write out. fsync is on so that should not be happening but, I'm ignorant. That's what I have, I do hope it's of use to you. As you know S-L is in flux right now but I'm small and use only a fraction of its abilities. A long time ago I managed to get my 2.8-era data into LedgerSMB for the sole reason that I loved the interface used in Cash > Reconciliation. But over time it began expecting more and more perl for more and more reasons. The install process was so convoluted and so often failed. Now the answer seems to be getting an install that actually works and wrapping it up as a Docker app and telling the user to run that, which makes it a first cousin to a binary blob. No thanks. I've attached an image of the artifacts in dark.css I mentioned earlier. Hope it's beneficial.

[Tekki]

In short, I tried 2.3.12.039 and nothing has changed.

How did you install the new code?