In IT, encrpytion algorithms can't be secret....
... so they have to rely on their robustness to cryptographic attacks only.
As the IT world continues to suffer the after-effects of 20-year-old botched Y2K fixes, please take a moment to enjoy a bonus Y2K tale of Microsoft Access 97 taking the place of a mainframe at a particularly paranoid financial institution. Register reader "Jim" was employed in that time-limited role of "Y2K developer" for a …
Worked at a mainframe manufacturer that had an internal group create a company wide messaging board app in the 80's.
And to prove who you were you signed into it with a user id and password. There was a message thread worrying about if the passwords were encrypted well enough. The developers said yes trust us they are encrypted. Trust was in short supply.
Well I eventually thought to check it out. I worked on the program that read the log file. No problem for me figuring out what files the messaging app used. At our location someone had made a file view program that could look at files in all kinds of encodings, binary, octal, hex, ASCII, FIELDATA...
So I saved a few copies of the messaging programs file then changed my password a few times and compared the files.
Hum, the encrypting didn't seem that good. Looked at it a bit then noticed a pattern. It looked like EBCDIC. Hey the file view program even did EBCDIC to so I looked and saw I was right. And then I sent a private message to the developers saying I checked and the encrypting was not encrypting.
"And then I sent a private message to the developers saying I checked and the encrypting was not encrypting."
The correct response would have been to get the developer's password, and post the message from them to everyone else.
The BoFH response would have been to get the developer's password, and post smut to everyone else.
The first bit of production software I ever wrote was in Access / VBA. When I was discussing it with a few mates (all IT professionals), one scoffed and said it wasn't a real database (i.e. not SQL, which is what he worked with). I still have a soft spot for it, as it can be a surprisingly effective tool in the right circumstances.
The main problem with Access is that it makes it really easy for users to bypass IT.
We've had a user who, over the years, moved a lot within the company and that, in every department he was in, he left MS Access apps that all became business critical. Over the years we've been porting them all into our internal platform, but they seem to still keep popping up everywhere!
"The main problem" is perhaps the wrong way of looking at it. If all these Access databases and Excel spreadsheets became business critical then perhaps he was doing entirely the right thing!
Going the corporate 'full IT' way with these things can be very difficult and challenging, especially without first having proof of concept or working model. Irrespective of whether the model owner and IT bods are in agreement, there's always at least one, or more layers of management level funding decisions to be made in-between.
I hold my hand up here, the situation was exactly as MiguelC describes. I was that guy, and yes my code did hook in to "god knows what" as CaptainScarlet suggested.
But... my team was starved of resource. I asked for SQL and was turned down, so I used what tools I had to hand. A year later, the three-month backlog of work for my team had disappeared. The quality of the work we were doing had shot up. I was saving the business something between £200k and £300k in labour costs. And all the while, I was telling upper management that this software was business critical, I was the only one who knew how it worked, and I hadn't been allowed the time to document any of it.
I left the company after my entire team were made redundant. I had a redundancy date 'pencilled in' and pushed back several months in a row, yet my software was still in active use in several teams. I have no idea what happened to my software after that.
So Access... yes there are better tools for the job. But it can be damned useful in a pinch. And it was my ladder into proper software development :)
"I left the company after my entire team were made redundant. I had a redundancy date 'pencilled in' and pushed back several months in a row, yet my software was still in active use in several teams. I have no idea what happened to my software after that."
You warned them - meaning you discharged your responsibility. What happened after that point isn't your problem or your liability, but I'd make DAMNED sure I kept copies of the correspondence.
This is SO TRUE. Most companies either have short-sighted management who won't give their workers the IT resources they need to do their jobs, or they've got an IT department that doesn't give a damn about user needs and/or isn't allowed or interested enough to talk to the actual users to see what their needs might be (see government IT).
So a few skilled individuals do "guerrilla IT" using tools like Excel or Access to try to get their jobs done and get bugger all thanks for it, frequently the opposite for "unauthorized activity." Later, their little projects end up becoming business critical systems, but since the systems were never documented properly, and the creators are retired or were laid off to make room for younger, more malleable, lower-paid employees, it's difficult at best to alter if business needs change.
So, are these things in source control? Do they comply with regulatory issues? What access controls are appropriate for the work that they do, and are they in place? Is their function documented?
I fully agree that enterprise processes can get in the way of getting things working. And skunkworking a POC is a well-honored solution in many cases. But when businesses come to rely on such things, the entire enterprise becomes vulnerable.
It's all fun and games until the auditor drop by or the knowledgeable person leaves.
>>a user... moved a lot within the company....left MS Access apps that all became business critical.
Yeah, I'm guilty of this too. I really liked using Access for quickly generating a prototype.
Unfortunately, some users tended to run off with these and before I knew it, whole departments were relying on the damn things. What's worse, along the way some users learned enough Access skills to be fairly dangerous on their own.
Over the years I've manged to port only a few of these to the "proper" places. To my horror, there are plenty Access dbs still left. (Management resists allotting hours for fixings things that "already work").
At least I've learned my lesson. These days I may still use Access for roughing something out but... I would not share the files with anyone.
I thought I'd finally forgotten the horrors of that sort of tomfoolery.
Used to just deny all knowledge of Excel (and VBA) so I didn't get roped into that eldritch horror.
Extra points as it was hooked into an accounts database running a foxpro database that used access to kick it back into life after it would enevitably fall over after hitting its max file limit (all too frequently...).
For the record this was within the last decade. In the 6+ years since I've left the place I can still see my touches on their website *sigh*, so who knows. The foxpro/excel combo might be still lingering on.
> The main problem with Access is that it makes it really easy for users to bypass IT.
I once worked a financial services company whose offshore arm included some people working on the actuarial team who, with justification at least once*, regularly bypassed IT. A PFY in the team came up with some swanky idea based on an Access database. One day the regulators asked some awkward questions the answers to which should have come from that Access database. Only the database turned out to be built on quicksand, and it took a lot of proper development and a regulator threatening to shut the business in 24 hours to dig out of the hole.
It was such a scare, it made me forbid Access unless there was some over-riding reason that absolutely could not be resolved in any other way.
Fast forward 10 years or so. The CFO of the company I worked for, pharma this time, took on a PFY, who soon asked for Access. I explained my concerns to the CFO, especially as most of what the PFY was planning could come from the accounting system. He over-rode me and ordered me to produce a copy for the PFY.
(Have you guessed what's about to happen?) Once I saw what the PFY was doing, I again approached the CFO and suggested he might want to intervene, as the guy was effectively writing his own accounting system. I was told I had a personal grudge against the PFY and had better improve my attitude.
Then, one fateful day, when the auditors were swarming around the place during some M&A activity, the Access database, as expected started spewing garbage. It took the chief accountant a week of working deep into the night to retrieve the situation, which was more than a mere embarrassment - it was beginning to look like a systematic swindle to the auditors, who said as much.
The PFY left a few days later.
"The PFY left a few days later." Did he really last that long after such a monumental cluster fuck? Did the CFO last that long too? I'm assuming CFO != Chief Accountant.
And it's interactions like this that you make sure you have in triplicate, including hard copy, ready for the inevitable
search for someone to blame investigation: "I explained my concerns to the CFO, especially as most of what the PFY was planning could come from the accounting system. He over-rode me and ordered me to produce a copy for the PFY."
> Did he really last that long after such a monumental cluster fuck? Did the CFO last that long too? I'm assuming CFO != Chief Accountant.
Yes, I' m afraid it did. Off he went in his Porsche... No, the CFO didn't last that much longer, I'm pleased to say. He was way out of his depth .
"He over-rode me and ordered me to produce a copy for the PFY.
....Once I saw what the PFY was doing...
....I was told I had a personal grudge...
....it was beginning to look like a systematic swindle to the auditors...
....The PFY left a few days later."
Except it wasn't JUST the PFY who should have left - and with a correspondance trail handed to the auditors, it wouldn't have been.
That 'CFO' was (and is) a liability to the company.
This is why where I work we don't deploy Access in our Office deployments. We've been bitten too many times by the rogue user who sets up a small Access DB to do a task which then becomes important. We had a guy working full time for 2 years on converting some these DB's to SQL with front ends for where we couldn't buy a off the shelf package that did the same task.
There are a couple of lessons here:
1) If the Access user wizard can identify solutions for (in)efficiencies in the various departments he's worked to the extent that his solutions become business critical why didn't the IT management supported him to get the job completed properly? Sounds like a bad case of 'Not Invented Here' to me.
2) really easy for users to bypass IT Two things here: Who gave the users the tools to bypass IT - if you didn't want them to use Access then why the hell was it installed? And why do the users feel the need to bypass IT? This looks like a failure of IT management to be either helpful or secure.
And no, insisting that IT call their colleagues in the other departments 'customers' or outsourcing their jobs does not fix any of this - are you listening former Ms 'Service Delivery Manager'?.
I used to do a lot of prototyping on Access, then create scripts to convert it to Oracle, MySQL or SQLServer, once I had the basic model sorted - the database modelling on Access was a lot better than Oracle, or at least a lot cheaper.
Later there were some good open source and low-priced tools that did a good job, but back in the early days, Access had its uses.
I got my introduction to databases in Access 1.1. After moving on to bigger things, I still used Access to model databases for a while. It would link to SQL Server and export table definitions so easily, and may as well have been free in comparison with other data modelling software of those days.
The problem with Access is it is a file-based database, so all concurrent users need to have physical access to the files - as it happened with dBase and FoxPro. As long as it was accessed locally by a single user, little issues. When it was accessed by multiple users over a file-sharing protocol issues could become more serious, especially on shaky or slow networks (far less common today, a bigger issue years ago).
The advantage of real RDBMS wasn't much SQL - as most databases after all use their own dialect and it's far less portable than it should (yes, I know the S is for "structured", not "standard") - it was their access over network protocols that ensure far better security and reliability, even on slower networks, with only the server accessing the file storage.
Not surprisingly, in the article each user got a separate copy of the database.
One of the most disastrous ways to implement MS-Access "applications" was to have the "application" and the "database" in the same damn file. Separate the two and a whole lot of pain suddenly disappeared. It also made it rather more obvious that using MS-Access as a front end into a "real database" was considerably better than relying on file-sharing concurrent access which Microsoft intentionally borked on anything other than Microsoft file servers... damn that was painful getting down to the bottom of.
But I was working for a large American bank who used Access to track their commercial client’s advanced requests for foreign exchange transactions (if they booked the request in advance then the FX desk could arrange better rates).
The problem was that this was one Access database replicated to multiple foreign branches (because Access databases do NOT work well across a WAN), and every time someone at one branch exited the system in other than a controlled fashion (by crashing, or by simply just turning their PC off for example) then they would break replication at their local branch copy. I had to hold this steaming pile together while a proper solution built around .NET and SQL server was built, and I’ve never forgiven it since.
I have a client with similar issues... and they've proposed/contracted/built at least 3 replacements for it in the last 12 years but each time it always gets to the "almost ready to deploy, just a few last tweaks" stage before fizzling out.
As a result they're still using the monstrosity.
Unfortunately their 'access guy' has passed away, so I'm left holding the reins :-(
I like Access a lot. I developed a scad of single-user niftiness using Access 97 and prototyped a megascad more for porting to a network-capable database.
I think when all is said and done, MS Access is like any other complex piece of software; if it starts showing odd behaviour or odd results it is a pretty good indicator it isn't being used within its designer's specification.
My personal fave was a system I wrote to fill time and track a code-conversion project I was budgeted to take six months on but actually spent one afternoon writing some SSG (call is perl for Unisys mainframe) and automated the thing so it all ran in less than an hour. Because the worthless bag of smell in charge hadn't requested disc quota, the results all got deleted, so I was forced to run the automation again. And again. I tracked all this on an Access database I wrote, as I said, just to have something interesting to do.
WBOS mused that it was a pity we had no way of knowing how far along the project was in terms of converted code. I disappeared for about an hour and provided him with a report of exactly what he asked for (a byproduct of mi'Access database). He bemoaned the fact that to be useful it would have to be grouped by one of the subordinate data items. I took the report away for about 30 minutes and brought it back the way he had wished, sighing theatrically, for.
After that he didn't ask me for anything else. I think I genuinely frightened him with mi'powers.
Best blade on the swiss army knife? Getting a full command of the combo box events. You can make absolutely gobsmacking proof of concept stuff once you've mastered that little trick.
One thing that could be said is that Office/VBA has had a damn good lifespan. I.e software that was written back then, still can mostly function now. The only other language that seems to offer that is C.
I wonder when the final bullet will be fired and Microsoft replaces the VB6/VBA component with .NET?
Or will it? Thinking about it now, I can actually see VB6/VBA outliving the .NET platform!
VB6 is long gone (more than 20 years now since Microsoft released a compiler that handled it, and out of support for many years), but VBA is so different to VB.NET that I suspect that they have to keep it for backwards compatibility. The problem is that Office would need to be rewritten into .NET (with the associated slowdowns) in order for a .NET based scripting language to make any sense (in general Win32 apps can only access .NET components if they have been exposed via COM, and these are in the minority)
We have a number of legacy databases kicking around. The problem is, one is Access 2003 - attached to a truck scale, which can't be migrated to anything newer.
Then we have another system for Access 2007, which uses features depricated in Access 2013... You have to ensure each application is opened with the correct version of Access, otherwise the newer version will try and auto-convert it and nothing will work and users on the correct version of Access can no longer access it.
"lost" the algorithm used for password encryption, which meant the whole "give me the second, fifth and eighth character" challenge wasn't going to fly.
Lets just pretend i know narthing...
So how does a bank verify your password when you tell them some of it , if the whole thing is encrypted?
Assuming encryption not hashing, then the answer is easy. Decrypt the password, check the characters provided, return true/false.
If hashing, the problem is actually worse. Even if they hash each combination of 3 characters, then any leakage is trivial to brute force. First 3 characters require 64^3 guesses, and then each additional one requires just 64 (assuming your bank actually allows 64 different characters in your password)
hmm , after a quick google to refresh terms like hash & salt, I assumed all passwords were hashed , but that does lead to the conundrum of "how can they ask for some it"?
The Guardian explains:
If a site such as a bank asks you to verify particular characters of your password, rather than enter the whole thing, it is encrypting your password as it must decrypt it and verify individual characters rather than simply match the whole password to a stored hash.
Encrypted passwords are typically used for second-factor verification, rather than as the primary login factor.
So a rogue Santander employee could decyrpt everyones passwords and go see where alse they used them. great.
It depends how the HSM is configured and how the keys are imported in the HSM: in certain configurations, the keys can easily be exported if one has access to the HSM. I'm on the development side of things (using PKCS 11 to communicate between the software and the HSM) and due to some requirement on the software, the clients using a certain brand of HSM have to leave a few export options available.
An alternative method is to store a salted hash for the full password that you and an external attacker would have to provide, plus three randomly-selected characters that they can use to verify you. That does reduce the number of possibilities for an attacker who has both the hashes and those letters, but by far less than a rolling hash or simple encryption.
Hey! I can understand some of the hatred for Access, but Excel always seems to be an easy soft target. For all the criticism it gets it actually does a great job for most people in most circumstances.
As for Access or Excel not being 'proper' solutions, show me an alternative that 'ordinary' people can use without specialist IT training? The difference is ownership. Sure, if I contract out building a custom SQL database to run a particular business model or application, then I expect to need IT professional support to operate it. But show me a consumer level equivalent. Most people have other specialisms and responsibilities beyond being DB admins or system architects. These office level tools just let normal people get on with whatever they need to do. If there was a consumer level 'Office' style implementation of a 'proper' database would this solve more problems, or create more problems?
I think its just habit, blame MS
...as opposed to whatever combination of budget restraints, bad management, anemic dev budgets or whatever else caused someone to make *their* job easier with a spreadsheet & VB. Then saw that become a pondering monolith, barely strung together with hasty kludges and hand coddled at the end of the month to run the business critical task that the company depends on.
SQL is not a "proper database" but a collection of similar but different extensions to a basic set of clumsy scripts to access and manipulate utterly different underlying data-storage systems.
Believe me, I've been there, done that, and have the T-shirt. Writing code to query the provider for its name, version, and locale before knowing which dialect to use in driving it is decidedly non-trivial.
The global financial crisis was caused by a wetware failure, not a software failure.
You can't make a profit by lending to people who can't afford to pay it back, no matter what financial wizardry you perform. Ultimately, the return comes from the people paying back the loans, and if they don't have money, there is no return.
Adding "on the internet" to a business plan does not guarantee unlimited returns, or indeed any returns at all.
Yep - spoke to a local bank clerk, she had told here manglement that lending on those terms (0.25% spread on Euroibor) made no sense and was going to lose tha bank money. The answer was "shut up and meet your lending target" or words to that effect.
Good news is we got one of those. Free loan.
Yep, it is a mid-sized mainframe. I used to work on a S/36 and a S/38 as a student on placement at Upjohn's. I had to write some RGP/II and RPG/III to monitor
disk DASD usage.
Our IT director in the 'States is an ex-IBMer and we were talking last week about a VMware machine and he wanted to make the "DASD" bigger on one of the clients.
No, it’s a mid to large sized mini. IBM mainframes were descended from the venerable 360 range (which became the 370, which became the 3090, and these days I believe is called the system Z). The S/38 was designed from scratch as a Mini back in about 1978.
The 3090 (from about the same period) was designed to handle hundreds if not thousands of users. The S/38 would top out at a couple of dozen.
System/360 -> System/370 -> System/390 -> System z -> IBM Z
My recollection, not backed up by anything, Wikipedia disagrees and I say they're wrong in no small part because they simply redirect System z to IBM Z and retcon the z900 as the latter.
None of this is helped by the conflation and confluence of architecture names and marketing names.
System/38 is not a mainframe. A static copy of a database is not a replacement for the source system from which the copy was obtained. I wonder if a copy of the CD was made by any of the staff.
Definitely a mini, not a mainframe. I wasn't really using IBM at that point, at least not beyond the desktop. I think it was basically the successor for the S/38 market.
I remember that we took over a contract for a shipping company and our computer room suddenly started to fill up. We had only a couple of MicroVAX sitting in the corner, with a desk-draw roller unit sized disk array with 4GB of storage (a huge amount of storage back then) and this 4' x 4' x 6' monstrosity with an IBM badge turned up in the server room.
I asked, what the fsck is that? Oh, it is a disk drive. I looked at the MicroVAX, looked back at the "tower", wow, how many hundreds of gigabytes of storage does it have? :-O Oh, only around 500MB. :-D
Access applications could be dreadful, particularly when produced by a user to get a job done; but as usual, a bit of thought could produce a useful and stable solution. Access 97 was OK, Access 95 was dreadful. We produced a number of applications for $1million-$10million p.a. organizations. The rough rule was: Always split the application into a front-end (forms, code, and reports); and a back-end (data, relations, and rules/integrity). An Access back-end was usually OK for ~5 concurrent users and 10s of thousands of rows of data on a reliable network - For important data, or more users, or an imperfect network, replacing the back end with an MS SQL Server (V6 at the time) could produce a fast and reliable application. For Y2K we replaced several green screen mini-computer applications with Access/SQL Server systems - Typically a few hundred thousand rows and 20 concurrent users.
Originally I had been developing applications with traditional Oracle type systems; but after we prototyped something in Access for a customer with the intention of upscaling to a “proper system”, the customer said the prototype works fine so why would you do that?
We picked up quite a lot of work because most of our competitors were doing what we had been: Big databases with lots of code. Typically our prototyping took a couple of weeks with another week or so to upscale to a Server version. Having said that, the initial learning curve to get around undocumented bugs and performance issues was quite long, but I had been playing Access from version 1 and using version 2 for small systems. One reason that Access was not popular with professional developers was that it required 6-8MB of RAM when many desktops had <=4MB, but we usually quoted to upgrade the punters’ PCs and still came in cheaper than the typical MS VB-SQL/Powerbuilder shops who would quote several months for development time. I’ve been retired for a while, but the company still has many customers using updated applications with the latest versions of Access and SQL Server.
Around Y2K I did a bunch of Access front ends. At the time the tools available for writing complex clients with lots of forms were some combination of awful, expensive, unreliable and complicated. Our team could knock out an app against a SQL Server back end before a Powerbuilder contractor could be hired or the java guys could decide on struts vs spring.
I used Quick Basic to capture stream data and format it into DBase data base files. Then Clipper to assemble that into a stream of activity reports back in the days before integrated Office suites. In some cases Lotus 123 was invoked, only to draw graphs, which then loaded word-processing for automatically written letters to be sent to international correspondents. Programs were loaded, used and dropped when down returning control to the main program. This was all back in the times of DOS 3 or thereabouts. In fact some PCs were used to take live data from more than one serial port source, process each stream into reports and send them on their merry way to different operational areas. One was a staffing report that analysed work demands and produced draft 24 hour staffing schemes. You could do a lot of work with a 8088 PC working in 640k of memory.
Downloading accounts data out of the IBM mainframe reformatting it and auto-loading it into online customer service systems was fun and far faster than a two person manual team achieved. They took 2 weeks and made errors, the machine brought that down to just over two hours, reporting every odd event it found. Those old systems managed what felt like miracles at the time. Of course, they look like rubbish now.
Yes QB was brilliant for data acquisition. We used it on Netware/PC-LAN networks to talk to instruments. About 40 lines of code would open a file, open a serial port, download data to the file, copy the file to a "safe" folder, check that the "safe" file was OK, tell the instrument to delete the data at its end, and then close the serial port. The data file was then used to load data into a database - At the time we often used R:Base as it was about the only SQL compliant DB for the PC. This worked well for about 100 scientists/engineers on about 10 different networks. We could then merge the data into a bigger DB.
I think that was dBase (II, III) I used around the end of the 80's to implement the accounting of our non-for-profit organisation: maintain the list of membership, maintain the list of subscribers to our magazine, call for renewals (these were proper letters, the body of the letter extracted from dBase and then formatted in LaTeX and send by snail mail).
For our couple hundred members, it worked fine enough. I moved abroad in 93 and left my function of treasurer, so I don't know what it became after that.
Reminds me of a time my firm was looking at taking over a struggling competitor, and their directors came down to sell the deal to us. While running through the back end procedures they showed us a shortcut they just ran to update the database with external data. I asked him to open it just to see what it did, only to find that is was a bomb intended to shut down the database server, rename all the database files and restart the database server, all the while displaying various fragmentation and reconfiguration messages.
They'd not been paying their developer who decided to get his own back. Needless to say, they deal fell through, and they went bust.
Saw the inside of the embryonic Internet Banking section of large UK finance house around Y2K. Despite it supposedly being an IBM/LOTUS shop there was an amazing MS Office ecosystem of Access databases, Excel Spreadsheets, Word Macros and Mail Merges powered by over 50 Access Databases, including one that ran the dozen or so seats of the Call Centre. Despite it being the essential engine of the company's internet banking department, large chunks were not backed up.
Put me off internet banking for decades.
My current workplace, a very important body both in my country and for countries around the world, uses a very large access database still, that was written some twenty years ago, before a few of my colleagues were ever born. And you can tell. Still uses the same 8bit color palette, still has a fax field for personal records, into which we put cell numbers. This database is vital for operation and there is a team tasked with essentially curating it enough to keep it going, even now as we move into Windows 10. It doesn't even work that well. I've asked for things to be added to it, I could even write it myself, but nooooo. Haha. Terrible.
This used to happen all the time within a bank payments department around the turn of the century into the present day. The system is down but the card payments and ATM withdrawals still work. Don’t tell the merchants on punters though. Now it’s it just it’s broken again and nothing works and costs everyone. #spreadsheetville #keepthemusicgoingitsawedding
I have long suspected that all recruitment "consultants" could be replaced with a reasonably simple SELECT query...
I actually got to prove this many moons ago with my first commission of independent tech work - my then girlfriend (now wife and mother to our first child) had a 'year in industry' job as part of her degree course and was placed at an agency of sorts that provided health related training and they needed a business application to manage job vacancies and applicants.
I mentioned I could build something for a price - negotiations went well and an Access db was created that essentially had two main tables with a many-to-many relationship that represented applications from applicants to vacancies. It worked, I got paid
Later it turned out that the owner was .... less than scrupulous (I had my doubts after working even for only a few days) and this resulted in my partner being removed by the University from her placement and no further placements would happen with them - yup that bad
Anywho fastforward many years later (5?) I got a call on my mobile from an unrecognised number asking for support on this very application at which point I quizzed the person calling (turns out they has swapped
cheap labour sources universities) and I politely declined the opportunity to proide support but recommended a check on disk space/old records to be removed - my bad for actually putting my personal mobile in the 'help' dialogue on the app!
Turns out a simple set of tables and select query can indeed be used as a complete implementation of a recruitment agency!
I've been eating out on Access for the last 20 years, first job was ironically Y2K proofing a shed load of financial apps. It seems that there are a lot of companies with legacy VBA apps of varying quality where the original developer has either left, died of natural causes or took their own life due to desperation.
It's still a good prototyping and basic database training tool, although it obviously shouldn't be used for heavy crunching or customer facing solutions. When the only tool you have is a hammer, every problem becomes a nail and we have stretched this application further than we should have. If it's a choice between waiting a year for a professionally developed .net solution or knocking up a quick two week bodge job in Access, guess what usually happens? Hence the legacy plague.
Sort of shot myself in the foot though, as being the last one in the team to leave, have naturally become a key dependancy and therefore am missing out on the current round of juicy redundancies.
Biting the hand that feeds IT © 1998–2020