I ask because the company I’m working for has a significant number of its applications, even those for its website, written in FoxPro .prg’s/.frx’s, etc, all running FoxPro databases.
I’m finding this extremely frustrating because I’m used to the way things were at my old company - a MS SQL shop using .NET development tools - where you could ask for a specific update to one of the custom-written programs and have it implemented in mere hours. Need a TPS report that shows the number of users who had a metric fall below a certain level? And you need it to tie across the past two years of work? No problem.
Need a button that will export selected data in Excel/PDF/.TIFF/etc formats? No problem
Here: Big Problem. “We can’t do that”. “You’re talking about a project that will take months.” (This last to a request for our custom-written mapping program to make a call on a very small table. I know this request might have taken my previous employers IT dept. 1/2 hour to implement because it’s the exact same request I had of them one day.)
Also… what sort of IT head, when asked to modify one of our most integral web applications, is capable of saying “We can’t modify the web application because we lost the source code”? Is “losing the source code” even possible?
Sorry… I guess that last paragraph was a bit of a rant. I know it’s possible to lose your source code. I just don’t know how it’s possible to lose the source code and keep your job.
But, for all you developers out there, what sort of development language is FoxPro, what are its strengths and weaknesses? I thought flat databases went out of favor sometime in the late 90s, early 2000s. (All our stuff has been coded since 2004).
It doesn’t sound like FoxPro is the problem, it sounds like you’ve got an incompetent IT department or one mired in bureaucratic idiocy. Believe me, I know what it’s like to work in one, even though I got to use my favorite languages and tools while there, it was physically impossible to get anything done in a reasonable way.
As for FoxPro, it is also a Microsoft product (since 1992) and is a distant descendant of the dBase family of integrated database/report generation languages.
I haven’t used it, though I did hack a lot of dBase code way back in the day. From what I hear, it’s pretty typical of the genre and about as useful as any similar tool.
I used FoxPro back in the 1990s (v2.5, DOS) when my previous employer had a routing application built on it. It was fine for what it was, but there was no way in hell we would’ve been able to integrate the FoxPro program into a larger integrated system that handled customer service, call center data, routing, recruiting and even timekeeping, much less built a web component for these functions.
For that project, we used the above-mentioned SQL/.NET technologies. I was actually in charge of the project and I never even considered FoxPro for such a task.
One of the irritating things about the version of FoxPro that we use is that MS Access ('03 and '07 versions) can’t be arsed to import the tables, telling me that the format isn’t recognized. :rolleyes:
It certainly shouldn’t be! Another vote for “incompetent IT department” here. Actually using an app that’s impossible to maintain (and that was written by somebody too stupid to understand the concepts of “code repositories” and “backups”) is just insane.
In this case, it appears that FoxPro’s strengths and weaknesses are overshadowed by your developers’ attitude and skillset.
Well the .NET Framework really didn’t take off until version NET 2.0 (2005) so a shop being hesitant about using it back in 2004 would be somewhat understandable.
What’s unforgivable is not realizing that FoxPro was already dead back in 1999. Using it as late as 2004 is just an example of dinosaurs insisting on clinging to the tools they are used to instead of switching to something more modern.
When Microsoft acquired FoxPro in 1993, many of us already saw the writing was on the wall saying FoxPro was dead. Microsoft just wanted FoxPro’s customer base (the developers.) They had no real incentive to put 1st class innovation into the product.
It’s possible, but it strongly indicates serious deficiencies in procedure (Where are the backups? What else isn’t being backed up properly?).
That said, it happened to me once - it could have been avoided with more sensible backup procedures than we actually had - there were two of us developing the same collection of applications - we would ‘check out’ the source code to work on it, then check it back in when it was modified and tested, but that system was only controlled by humans - and the other guy checked in an old copy of code he had not been working on, overwriting changes I had made.
Because no further modifications were needed to that application for several months, the earlier source version managed to propagate out to all of the rolling backups.
So we ended up with an application that could not be maintained without losing some of its function.
Either have your IT department fired or change jobs. The place you’re working is on its way into the gutter with a bunch of incompetents like that in IT, and obviously incompetent management for keeping them.
I can’t even begin to describe how badly they are doing their jobs.
Before we all slam the IT shop, I’ve seen plenty of these horror stories that stem directly from top managment taking an “If it ain’t critically broke, don’t spend money on it.” approach.
For a slow-moving part of their business, like the factory machinery to stamp out steel widgets, that’s probably a decent approach. For a fast-moving part of their business like IT, that’s a certain recipe to coast & save money for 5-10 years, then crash spectacularly.
And these folks are rapidly approaching the crash. Clearly the IT shop is not full of leading-edge practitioners. But it probably got that way because the Head Cheese didn’t want to invest in those kind of people doing that kind of work.
I agree this is not a ship you want to join, unless …
Top managment has woken up and you have been given the mandate & budget to build a new IT shop alongside the old. And you have the cojones to do that, and then to shut the old one down in its entirity.
Not quite, given that the first microcomputer was the Sac State 8008, from 1972. This computer was the first to be built around a ‘computer-on-a-chip’ CPU: One die that contained an entire central processing unit, as opposed to earlier desktop systems, like the Kenbak-1 and the Datapoint 2200, whose CPUs were built from multiple components.
(Why am I posting this here? Because practically nobody knows about this machine anymore and that’s just sad.)