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.
Read more from SeisWare’s Blog>
Follow SeisWare on social media
Do you need to ramp up your drilling program? Is it time to build upon your field development plan? Do you need a kick-off point for data analytics? We encourage you to check out our […]
OptiSeis is driving seismic acquisition to lower environmental impact – and SeisWare is there to help. OptiSeis is making waves. Both figuratively and literally. Over the past few years, OptiSeis has been researching new ways to […]
Three tips to boost your workflow efficiency What turns an ordinary SeisWare user into a power user? Other than experience, knowing what tools exist to simplify everyday tasks is key. To give you a head […]
