And it's plain visible that I was rather absent from the office while this lasted. In Kosta I found only this left:
Seventh, Brlja and I were atu Svemiks. Eighth and ninth, tieing workorders with the goods warehousing in Bangro, because from accounting point of view it's screwy to pull the goods from retail (parts, consumables) and insert back into production, i.e. the repair shop. But once we write it it ceases to be a problem, just type in what was taken, and it creates a document which makes it legal and okay and all asses covered, tax recalculated and the work can continue smoothly.
Tenth. „Fixed bottlenecks in the internal cash app. Added copying of analytics codes from the ledger when needed. Cleared up the uncertainties around checks and gasoline chits. Small add-ons in ledger and invoicing“... I had hard time remembering who this was, who had gasoline chits and checks: it was CD. To differ from the pretty much identical app I had four years ago, which had hundred faults and kept draining my time for as long as I was at hand to keep pushing it, this one went into production rather quickly, and the two chicks who worked in that tight room by the entrance got into routine rather quickly, the work flowed smoothly, and they didn't call me too often.
In their main office was one, I must say lady because that was her stature, always in a dress but with some discrete window into the cleavage and on the sides at the bottom, tight to the body, sat upright at all times, one leg over another, in case there was anyone who didn't notice the cut... and she was built, indeed. The face was pretty, too, but I can't remember it in any detail. And then this spring she sent her daughter to us, to print her matricular paper on the laser. Ooooowch, daughter was even prettier. Luckily, we had to go somewhere, left her with Cica, so nobody heard how we sighed.
On fourteenth somewhere we „reconfigured server - parameters, memory“, must be I ran the kewemem until K.O., and „disk maintenance on other two machines, and those are still 386s!“. Whoa.... this sounds familiar, this must have been the Ledinje... they had a time when one machine would often drop out of network, or the one which acted as a server would freeze its display but keep on serving files to the others. So we taught them all to quit, relaunch the app, do something small, save, quit again and then reboot that box. That way we made sure the tables are in healthy state and nothing was lost, except maybe the current entry on that box. And we ran defragmentation often, just to be seen doing something while we enjoyed the coffee and their heavenly yogurt with probably 5% of milk fat. At least we didn't call it compression anymore, as we ran Norton's defrag instead of the once compress from Pitchy Toolz.
The same day, at some other customer, I see its code was 1252 while almost all others were below 1100, „training and details on the ledger scheme“, so I must have had to play the old record about analytics and why customer and supplier codes need not be erased every year and should not be in separate lists because it's just a list of business partners, some of them will surely appear as both a supplier and a customer and you may also charge them interest, so why would they appear in three places and have three codes if they are the same entity in all these cases... In the comment of the record I wrote „white birds, can't be whiter“. It's an old quip, at lest eight years old, „big white birds, not swans“ were the office shorthand for lightly trained and partially literate operator girls.
For some other firm with just as high code, on eighteenth, „setup the printer (852, page size, automatic eject for tear-off). Few details in the ledger. They are again without network because yet another couple of their machines were stolen...“.
On UA, wrote this:
Just an idea - how about building a view within a temp .dbc, with proper ordering, and then opening the view with the alias needed for the form. The view would be built from scratch every time (though issuing all of the *setprop()'s every time would be a nuisance), and its SQL statement could be built using the currently preferred ordering of fields. Could be done in the .Load of the form.
The .dbc could be discarded on QUIT.
The incredible part of this is the date when I wrote it. Because I did exactly that a few years later and turned out to be not just right about it, but it got the whole thing load at least one order of magnitude faster and removed some problems we didn't even realize we had. The whole views thing is just a simulation of work with a database server, the good side of which is that the data travel the wire only twice, once when it's loaded, and once when its changes are saved, and meanwhile this view is actually just a set of records, in workstation's memory or on its disk, so it's local.
What made it slow were the definitions of the views, all of which resided in a table on server's disk, which was crowded with too many people demanding records from it at the same time, which made it slow. Having learned to generate various kinds of code long ago, and knowing that the whole views database could be defined programmatically, I wrote such a code, which will create such a database with just views, from scratch. And then... this database needs to know where the database with the source tables, that the views are looking into, resudes, but the other way it's not connected at all. The target tables are ignorant of the very existence of views, so the views database doesn't have to be in the same directory, on the same disk, or, for that matter, on the same machine. It can be local, every user can have his own, on his local disk, no crowding.
The moment I made that, the app soared. It's just that I can't remember when was it - 2001, 2004 or 2007 or even later.
Afterall, real programmers don't use App. Generators ;-)
Yep! They write them :)
18-I-2025 - 19-VIII-2025