Solved 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%.
-
@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.
-
@travisdh1 said in Taking suggestions about x86 Access replacement:
@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.
By this he means good developers. Shitty .NET devs are a dime a dozen, the kind that screw you over like crazy. PHP shiity devs are everywhere too. The difference is that good ones are exceedingly rare in .NET because its an ecosystem of being crappy.
-
To be sure, you could write this in Go, Rust, Java, Python, Ruby, etc. Some languages, like Python or Ruby, would lean towards easy and practical. Others, like Java, would introduce a lot of unnecessary overhead that you can avoid. But they will all work.
-
@scottalanmiller said in Taking suggestions about x86 Access replacement:
Whereas PHP is absolutely 100% the language built for this task.
That is so true. Initially PHP was an abbreviation of Personal Home Page. That's how much is what built for this task!
All the other languages have been constructed but PHP has been dynamically expanded to what it is today - based on the needs of developers over the years. That's why it's relatively easy to do what you need with it.
I'd always thought of it as an interpreted dynamic version of C. Considering that C is the foundation of the entire unix/linux universe it made perfect sense to build PHP on that syntax.
