The 'fx pedal to end all pedals' has ended its career

 The musical group had a knock-about session last night, playing anything that came into our collective head (eg 'Hotel California', 'Forever young' (Alphaville) and some Israeli songs - almost nothing that I have played before). Before we started, I checked out my pedal board and the fx pedal. I wrote ¹ two months ago that the 'fx pedal to end all pedals'² issues a fair amount of noise so in order to combat this, I set the noise gate to a level that let loud guitar through but not hiss. This caused the guitar to sound rather 'chunky' and lacking dynamics. Thinking about this on the way home, I realised that all the presets that I defined start with compression; maybe it would be better to create some presets with no compression and see what these sound like.

Before setting off for the rehearsal, I connected my phone to the pedal via bluetooth (and no small amount of bother) and attempted to remove the compression from all the settings. I think that I was partially successful in this. Despite my efforts, once I started playing, the sound from the amplifier was very weak. Exasperated, I disconnected the fx pedal from the system and suddenly my guitar volume increased ten-fold. I'll have to remove the pedal from the board and restore those that I previously removed.

On a completely different topic: yesterday was quite warm but this morning, when I was taking the dog for her morning walk, it started raining. Now that's not such an unusual event, but what makes it stand out is that the barometer in my head didn't give me a migraine. I did have an odd stomach ache in the evening, so this could be my body's new way of reacting, but it could also be due to the odd stomach rumblings from which I suffer now and then. So it looks like the new prophylactic pills³ that I have (that are meant for epileptics) are working.

Internal links
[1] 2074
[2] 2072
[3] 2095

---

This day in blog history:

Blog #	Date	Title	Tags
566	07/04/2013	A new technique in Word Automation	Programming, Office automation, HTML
822	07/04/2015	I've always kept a unicorn	Sandy Denny, Fotheringay
1119	07/04/2018	Season of the kumquat	Personal
1306	07/04/2020	Statistical methods for Epidemiologists	Statistics, Covid-19, Non-fiction books

Migration completed; now the debugging begins

At 5pm on Thursday afternoon, I completed the migration of the OP's management program with 354 units from ANSI Hebrew and dbExpress components to Unicode and FireDAC. When I write "completed", I mean that I had gone over every form and unit and replaced the dbExpress components with those of FireDAC. I also had briefly tested each form, but there was no guarantee that the program was free of bugs - in fact, I was fairly sure that the units that were first converted probably would not work correctly.

But before that, there was a topic that I had purposely not worked on, leaving it for the end. Almost all the forms that add data to the database have an autoincrement primary key; this is achieved by having a generator (something that returns a sequence of numbers, such as 1, 2, 3, ... 2001, 2002, etc) and a trigger that gets the next value from a generator and inserts it where needed. I didn't want functional generators when I was populating the new database from the old, but now that the translation had completed, I did need the generators and triggers for testing purposes. 

What I really needed was to drop all the generators and triggers before transferring any data, then to recreate them after all the data had been transferred. CoPilot got the dropping code partially correct - it would work if there was a trigger but wouldn't if there was no trigger. Eventually CP developed some complicated SQL code for a conditional delete. This also had to be done in the correct order: first delete the trigger then the generator; this is because the trigger refers to the generate. Recreating the generators and triggers was easy, at least when done in the correct order. Then the generators had to be seeded with their new starting value. Originally I wrote a small query that would return the maximum value in the key field and used this, but then I noticed that the migrator calculates how many rows are in a table (for a progress bar) so I used this - and shortly discovered that the number of rows is not necessarily the highest value of the key; there might have been deletions from the table. Eventually that was fixed and I migrated the database once more.

On Saturday morning, I started working through the program and found some simple problems to fix, for example queries that weren't attached to the database connection. I found more queries whose fields needed to be redefined, and I found some that were wrong because the columns to which they were connected were not defined correctly. This required a fix to the database and remigration of a single table. 

But there were some significant problems each of which took a few hours to fix. In what is probably the entire program's main form, the 'restore grid widths' routine wasn't working, although in fact, the correct values were returned but the grid 'ignored' them. The solution was to update the grid when all screen painting had finished, and so I added an OnPaint handler that sent a message to another procedure that would load the grid widths. This worked.

Another familiar problem occurred with a query called qSentReports: when certain reports are run, their HTML output is stored in a table so they can be retrieved at any stage. I had had problems when saving new reports in the table then restoring, so I assumed that retrieving reports that had been created in the previous version could be restored in a similar manner. But this was not so. According to CP, I was dealing with double or even triple encoding, involving WIN1255, WIN1252, UTF-16 and UTF-8. Then it struck me that the original data was already in UTF8 format, so the migrator shouldn't encode it and my code shouldn't decode it. After this epiphany, I once again transferred the data for this one table and finally it displayed correctly.

I am sure that there are further traps awaiting me, but I suspect that they will be minor. Now I don't know what to do with myself and all the free time that has suddenly opened up. 😉

---

This day in blog history:

Blog #	Date	Title	Tags
240	05/04/2010	Holiday	Cooking
346	05/04/2011	Firebird fixed!	Computers, Firebird
692	05/04/2014	Pneumonia	Health, Nick Drake
821	05/04/2015	Vinyl log 1 - 5 April	Vinyl log
937	05/04/2016	Sorrento shopping (2016/2)	Holiday, Sorrento, Italy
1118	05/04/2018	The sense of an ending (2)	Films, Literature
1207	05/04/2019	Excellent music blog	Beatles, Song writing
1597	05/04/2023	Passover night, 2023	Jewish holidays, Kibbutz
1920	05/04/2025	Slow cooked leg of lamb	Cooking, Slow cooker