Visual Basic was a major breakthrough in that it was the first widely adopted "visual" programming tool for Windows. But it had severe weaknesses from the start that were never fixed, even by the time they got to version 6. Borland's Delphi beat the crap out of VB - that is why Microsoft lured Anders Hejlsberg (and others) away from Borland in 1996. Anders "fixed" VB6 - by killing it and creating C#.

It's rare for an employer to fire a person simply because they gave notice. The only exception I can think of is if there was some type of security concern. It sounds like your boss just wanted you gone (for whatever reason). That being said, depending on where you are, you would probably qualify for unemployment benefits because that does not sound like legitimate grounds for termination. I've hired and managed programmers and I usually ask programmers to give 30 days notice if they are leaving and it typically takes more like 60-90 days to replace a programmer if you count the time needed to advertise, interview and then allow them to give notice and then to get them up to speed.

Personally, I'm with your architect. The most common reason given for using stored procs is that it provides some performance benefit but I have never seen that proven. The second reason that people like it is because it provides a layer of abstraction. Instead of looking at the SQL in your code, you simply call a descriptive SP like "getListOfThings" or "SetThingName". That does provide a benefit, especially if you have a large team with various experience levels working in the code - it makes the code more readable - but you can get the same benefit using other techniques. I personally have found that having a view of the actual SQL right there in the code is very valuable. It saves you the time of having to write SP's and/or go look up the SP to figure out if the bug you're looking for is in the code or in the SQL. A few years ago there was a lot of interest in Object Relational Models and basically finding a way to get the SQL into the code in a way that would allow the compiler to throw errors when there are mistakes in the SQL itself. I have not heard a lot about it lately But that whole concept sort of proves the point that having visibility of the SQL in your code is desirable. One last "benefit" that is often cited for using SP's is that you can fix a bug without having to do a new build of the app. And while that is true, there is a dark side to that as well. Many times the SQL needs to change from one build to the next. When you use SP's, you sometimes end up with "getListOfThings_1" and "getListOfThings_2" because you need one SP that works for one build and a different version of the SP that works with the next build. If you maintain the actual SQL in with the code, then the correct SQL for each build lives with that build.

Ah yes, I get that "hit by a bus" question quite often. I usually just tell clients that any programmer that can read English (especially a c# or java programmer) would have no problem taking over on a Delphi app. If they want to move away from Win32, I would move to a browser based app. The choices for development tools are endless and mostly underwhelming. I actually write browser apps by just creating the UI with HTML/CSS/javascript in a txt editor and then I write the server side piece (CGI) using Delphi (so then I still get to use the database and utility code that I've built over the last 15 years).

If your target is still a Win32 EXE there is no reason to use anything beyond Delphi 6. What prevents you from just enhancing your Delphi 7 code? If the target is now a web or mobile app, that's different.

Be glad that it's "unrelated" chatter. It's worse when sales or service is describing features or giving help in an app that you wrote and you keep thinking "noooooooooo! that isn't how it is supposed to be used"