Solved Taking suggestions about x86 Access replacement
-
@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.
-
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@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.
I happen to know some developers they could probably rewrite that for you
-
@jaredbusch said in Taking suggestions about x86 Access replacement:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@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.
I happen to know some developers they could probably rewrite that for you
LOL. Maybe even in something other than Access!
-
We sadly have the same thing here, people write things and then leave- classic IT story. How do you move forward when they left a decade ago and now no one can do anything with it, but it is a agency requirement?
We have some Access files here the same way, if it wasnât compiled it might have been okay, but compiled,.. ugh.
Depending on a number of factors, there may be a way to âstep it forwardâ... is yet to see off I canât hint that down
-
LOL. Maybe even in something other than Access!
I talked to the boss and he agreed to moving to a SQL Server. Now I'm researching a frontend for it.
-
@mr-jones said in Taking suggestions about x86 Access replacement:
LOL. Maybe even in something other than Access!
I talked to the boss and he agreed to moving to a SQL Server. Now I'm researching a frontend for it.
Access can be the front end. That's not a problem when using SQL Server. But if you can avoid Access, then PHP is the absolutely obvious answer. Don't even think about considering anything else, complete waste of time to even talk about it. Keep Access, or upgrade to PHP 8.
-
There are a few php/mysql builders online as well. some good, some bad.
-
@stuartjordan said in Taking suggestions about x86 Access replacement:
There are a few php/mysql builders online as well. some good, some bad.
If there is a good way to get from SQL Server to MySQL or PostgreSQL would be great. One additional step in the right direction.
-
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@mr-jones said in Taking suggestions about x86 Access replacement:
LOL. Maybe even in something other than Access!
I talked to the boss and he agreed to moving to a SQL Server. Now I'm researching a frontend for it.
Access can be the front end. That's not a problem when using SQL Server. But if you can avoid Access, then PHP is the absolutely obvious answer. Don't even think about considering anything else, complete waste of time to even talk about it. Keep Access, or upgrade to PHP 8.
I have very limited knowledge in this area so I am wondering why not a .Net front end instead of PHP?
-
@pmoncho said in Taking suggestions about x86 Access replacement:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@mr-jones said in Taking suggestions about x86 Access replacement:
LOL. Maybe even in something other than Access!
I talked to the boss and he agreed to moving to a SQL Server. Now I'm researching a frontend for it.
Access can be the front end. That's not a problem when using SQL Server. But if you can avoid Access, then PHP is the absolutely obvious answer. Don't even think about considering anything else, complete waste of time to even talk about it. Keep Access, or upgrade to PHP 8.
I have very limited knowledge in this area so I am wondering why not a .Net front end instead of PHP?
Server side performance, server licensing or compatibility, and ease of finding developers are the first few things off the top of my head.
-
@pmoncho said in Taking suggestions about x86 Access replacement:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@mr-jones said in Taking suggestions about x86 Access replacement:
LOL. Maybe even in something other than Access!
I talked to the boss and he agreed to moving to a SQL Server. Now I'm researching a frontend for it.
Access can be the front end. That's not a problem when using SQL Server. But if you can avoid Access, then PHP is the absolutely obvious answer. Don't even think about considering anything else, complete waste of time to even talk about it. Keep Access, or upgrade to PHP 8.
I have very limited knowledge in this area so I am wondering why not a .Net front end instead of PHP?
.NET isn't bad, the problem is that 99% of .NET developers are incompetent and it'll be very costly for you to find one that knows what they are doing and/or cares. Almost all people working in .NET do so to be lazy by using proprietary and costly packaged components that save them almost nothing and pass on cost and risk to their customers who are almost always too lazy to bother researching or auditing what they buy. So while at a technical level you can do anything in .NET that you can in PHP, in practice it's like playing Russian roulette with a gun with 100 chambers and 99 of them have bullets.
PHP all but guarantees that at the very least the packages are going to be portable and maintainable and at least makes it likely that you are dealing with everyone attempting to do something well. .NET all but guarantees the opposite.
Now, if you hired ME to do it, I could do it the same (poorly, but the same) in either language family. As could any competent and honest developer.
But the reality is, PHP is faster and easier. So doing it in .NET would have negatives for this just on a technical level. Harder to write in, harder to deploy, harder to maintain. Not bad, C# .NET and F# are fantastic languages, but not well suited to this work particularly. Whereas PHP is absolutely 100% the language built for this task.
