Often when you’re choosing a technology to use with your software, it can be hard to look far into the future. As amounts of data increase, complexity ramps up, and performance requirements become more difficult to achieve. A good choice for a piece of technology, which was excellent 10 years ago, sometimes begins to fall apart. Sometimes this is because it’s used in ways that it was never intended to. Sometimes the 3rd party supplying the technology has stopped new development, and it starts to fray at the seams.
Recently, we hit a limit for the Microsoft Access database technology we previously used for portable SeisWare projects. Fortunately, we saw this coming a couple of years ago and have technology in place to replace it (called SQL LocalDB). We’ve been using that primarily since then. We intended to support old projects that used an Access database if we could but after the next set of updates that will no longer be possible.
What limits are we hitting? Well, we can no longer add new datatypes to SeisWare in Access-backed projects. There’s a hard limit on the interconnectedness of database tables that we’re running into. There are also limits to how many applications can safely access the same DB at the same time without running the risk of corruption and repair attempts. And finally, Access can’t meet our modern performance requirements.
What does this mean for our users? Probably not much. Users haven’t been able to create new projects with an Access DB in quite some time, and they’ve been unable to convert projects to use it. There are also enough annoying performance warnings that pop up when you use it that it likely got people moving towards LocalDB anyhow. In any event, the biggest risk is having old, archived Access projects.
What can we do? Well, quite a bit. Converting a database has always been a fairly easy process, and we want to have the tools and support in place so that if you find a dusty old project lying in the deep recesses of a laptop wedged between your desk and your garbage can, you can upgrade it. We can also learn from this and write our code defensively so that when the time comes to swap out old technologies, it’s as safe and seamless as possible.
Change can be difficult and painful. And the older your code is, the more difficult and painful it can be. In the last year, we’ve changed our tactics when it comes to re-working our older code. Rather than wait until we’ve been painted into a corner, we have a group of people looking ahead to see what technologies are maturing and which ones are reaching the end of their lifespan. And instead of trying to wedge code refreshes in between all our other strategic objectives, we’ve got a separate stream of development dedicated to making sure SeisWare isn’t going stale.
Follow SeisWare on social media
Goals. Every company has them, but how many actually strive to make their goals a reality? While we would like to think that everyone does, the reality is that it is probably fewer then we […]
How SeisWare Built Its Leading Software Support Services We’ve all been there—a productive day can go sideways quickly when tech issues arise. When you encounter a software or a tech problem, the software support […]
From the depths of the Earth to the poles of Mars, SeisWare supports geoscience education and research initiatives. Research projects often have a limited budget. This may cause researchers to rely on interpretation solutions […]