Solved Taking suggestions about x86 Access replacement
-
@mr-jones said in Taking suggestions about x86 Access replacement:
Okay, let me preface this with "I'm not a database guy". Moving on.
We have two users who require 32bit Office suite to open a very old Access database. They are the only two in the entire organization who need 32 bit, and it's getting really old having to do everything for the OTHER database that EVERYONE uses (to include them) in both 64 and 32 so they can still use both.
My first and only idea so far is to swap them over to x64 Office suite, and then using VirtualBox or similar, make them a VM with x86 Office suite so they could run the old database.
This isn't a great solution, imo. These folks are not tech savvy and I feel like throwing a VM at them would make their heads explode.
I'm looking at Microsoft Access alternatives, but my priority would be to ensure the the database would function the same, and have the ability to be replicated or be imported from the old one with minimal issues. I don't know a lot about database stuff, and this just doesn't seem like a thing to me, or at least something where the solution would require me to rebuild everything from the ground up to match the old one, which at this point, I'm unable to do in any timely manner, but I'm open to suggestions and actively trying to learn about it.
Convert the access database to SQL and put it on Azure SQL on a tiny instance that's only spun up when uou need it
-
@irj said in
Convert the access database to SQL and put it on Azure SQL on a tiny instance that's only spun up when uou need it
I had a feeling SQL would be a suggested solution and have been watching videos on it. Does this sort of thing happen pretty seamlessly or does it take a big amount of setting up the tables, etc. before the import?
-
@pete-s said in
Are they just opening the MS Access database or are they actually running an MS Access application or some other application that is using the MS Access database?
They are opening the database directly, well the frontend of it I think. There's no software involved other than and Access database
(.accdb)(.accde) I know for sure. -
@mr-jones said in Taking suggestions about x86 Access replacement:
@irj said in
Convert the access database to SQL and put it on Azure SQL on a tiny instance that's only spun up when uou need it
I had a feeling SQL would be a suggested solution and have been watching videos on it. Does this sort of thing happen pretty seamlessly or does it take a big amount of setting up the tables, etc. before the import?
Generally pretty seamlessly. Access is built to do this.
-
I've not looked into this in forever, but is there no update process to Access DB files?
-
@mr-jones said in Taking suggestions about x86 Access replacement:
@pete-s said in
Are they just opening the MS Access database or are they actually running an MS Access application or some other application that is using the MS Access database?
They are opening the database directly, well the frontend of it I think. There's no software involved other than and Access database (.accdb) I know for sure.
If it's a .accdb file you should be able to convert into a 64-bit for the latest Access version. That should be the solution to the problem.
I mean, the issue here is that you need to install 32-bit Office just for this file and that is what you want to avoid correct?
Then it makes no sense moving it to something else. Access is more than just a database and can do things SQL Server can't.
-
@pete-s said in Taking suggestions about x86 Access replacement:
Then it makes no sense moving it to something else. Access is more than just a database and can do things SQL Server can't.
Yes, but that's not what anyone suggested. Access itself is a front end, and can choose AccessDB as a non-production backend or SQL Server as a production back end. The suggest that someone made earlier wasn't to abandon Access, but to upgrade from AccessDB to SQL Server as the database behind Access.
-
@mr-jones Can you tell us why they need 32 bit? We manage a ton of Access databases that were created and developed under 32 bit MS Access in the year 2003. With very little effort, these are all running just ducky under 64bit Access 2019.
I'm just curious if you may be having a problem that is simple to resolve, but since everyone has always said it has to be 32, the solution hasn't been explored....
-
@jasgot said in Taking suggestions about x86 Access replacement:
@mr-jones Can you tell us why they need 32 bit? We manage a ton of Access databases that were created and developed under 32 bit MS Access in the year 2003. With very little effort, these are all running just ducky under 64bit Access 2019.
I'm just curious if you may be having a problem that is simple to resolve, but since everyone has always said it has to be 32, the solution hasn't been explored....
Do you mind expanding on the "with very little effort" part? I'd like to know what that effort was. As it stands, when you try to open 32 bit with 64 bit Office, it flags an error of "This database was created with a 32-bit version of Microsoft Access. Please open it with the 32-bit version of Microsoft Access."
I'm learning this as I go, and reading that while it may be possible, it may also not be possible depending on the complexity of the database.
It's .accde btw, I messed that up earlier.
-
@scottalanmiller said in Taking suggestions about x86 Access replacement:
I've not looked into this in forever, but is there no update process to Access DB files?
I was mistaken and it is .accde which changes things.
Currently reading this article and it looks like I need to know more about how this was built before I will really know if it's possible. Conversion doesn't look simple.
https://www.devhut.net/2017/04/13/access-x32-vs-x64-compatibility/
-
@mr-jones said in Taking suggestions about x86 Access replacement:
I was mistaken and it is .accde which changes things.
Crap, yeah it does
-
@mr-jones said in Taking suggestions about x86 Access replacement:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
I've not looked into this in forever, but is there no update process to Access DB files?
I was mistaken and it is .accde which changes things.
Currently reading this article and it looks like I need to know more about how this was built before I will really know if it's possible. Conversion doesn't look simple.
https://www.devhut.net/2017/04/13/access-x32-vs-x64-compatibility/
At this point, this tells me that it's time to have a CTJ talk with the users of this system. How is something so completely unimportant that they are willing to use Access to do it, yet they have these critical systems that you have to do so much to support when everyone has known for a decade or more than they are only going to work for so much longer and some day they are just going to stop working with no upgrade path and everything will be lost. There's a mismatch here... using Access at all, let alone ancient, not updated Access tells us that whoever is using this thinks the data and processes are worthless. The need to support ancient software at ridiculous cost (this kind of stuff should be essentially free) implies the opposite. It can't be both.
If the data matters, they need to move to something practical and business class. Doesn't have to be crazy. Might just be a spreadsheet. Might be Access 64bit with SQL Server back end. Might be a "whipped up in a weekend" web app. Lots of options. But it needs to be done. If the data doesn't matter, they need to stop wasting resources to keep using it.
If these were my employees, I'd not be happy to find out that the company's data was locked away in silos like this.
-
@mr-jones said in Taking suggestions about x86 Access replacement:
accde
If this is an accde file, it has to be compiled for 64-bit.
You can mix bits if using different versions of the apps. Example, you can have 64 bit Office 2019 installed, (with or without Access). And then install 32bit Access 2016 and it will all work. I know you are not looking for that, but it will work.
Do you have access to the pre-compiled version of your access file?
-
If the data matters, they need to move to something practical and business class.
I'm with you 100%.
-
@mr-jones said in Taking suggestions about x86 Access replacement:
If the data matters, they need to move to something practical and business class.
I'm with you 100%.
What kind of data is it? Any why does no one else need access to it?
Is it ironic that an application called Access is the tool that blocks access?
-
Do you have access to the pre-compiled version of your access file?
I think it was made in the mid-90's. My guess is no, but I'm going to ask my boss. Is that a necessity?
-
@mr-jones said in Taking suggestions about x86 Access replacement:
Do you have access to the pre-compiled version of your access file?
I think it was made in the mid-90's. My guess is no, but I'm going to ask my boss. Is that a necessity?
Probably. Because Access is designed for you to always keep that. When you choose to use Access, whoever did that in the 90s, accepted that they'd have to always keep that in order for Access to be used long term. If they didn't keep it, it's another "actions speak louder than words" and someone decided this wasn't important and needed to go away.
-
What kind of data is it? Any why does no one else need access to it?
It's funny that you ask that, as I'm being told we kept it as a "convenience for the Registrar department". smh.
Still, the other broadly used database (64-bit) isn't written by us, and lacks some functionality the Registrar Dept. requires. I guess it's time to have a serious discussion with people above me.
Is it ironic that an application called Access is the tool that blocks access?
LOL, yes. Yes it is.
-
@mr-jones said in Taking suggestions about x86 Access replacement:
Do you have access to the pre-compiled version of your access file?
I think it was made in the mid-90's. My guess is no, but I'm going to ask my boss. Is that a necessity?
Probably much newer than that. I think the first version that did accde was Access 2007.
You probably bought your application from the "developer" without the source code. Meaning you can't change a thing. If you in fact did receive the source code, you probably have misplaced it.
-
@pete-s said in Taking suggestions about x86 Access replacement:
@mr-jones said in Taking suggestions about x86 Access replacement:
Do you have access to the pre-compiled version of your access file?
I think it was made in the mid-90's. My guess is no, but I'm going to ask my boss. Is that a necessity?
Probably much newer than that. I think the first version that did accde was Access 2007.
You probably bought your application from the "developer" without the source code. Meaning you can't change a thing. If you in fact did receive the source code, you probably have misplaced it.
Right, often the case, they decide it's a 100% dependency on the developer, for forever, from the get go.
