Solved Taking suggestions about x86 Access replacement
-
@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.
-
@pete-s said in Taking suggestions about x86 Access replacement:
@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.
Yeah, PHP really just... works for this stuff. So easy to use, so easy to support, SO easy to get a framework that does 99% of the work for you. And if you swing a dead cat, you whack at least three PHP developers. And those are just the developers that focus on PHP. PHP is so easy that pretty much any developer used to any other language can jump into it in an hour or two.
-
@scottalanmiller said in Taking suggestions about x86 Access replacement:
@pete-s said in Taking suggestions about x86 Access replacement:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
. And if you swing a dead cat, you whack at least three PHP developers.I have to remember that phrase. Gruesome but funny.
Thanks for the info and views of PHP. It is nice to hear some positives about PHP as I mostly read about the security issues surrounding the multiple versions of PHP.
-
@pmoncho 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:
@scottalanmiller said in Taking suggestions about x86 Access replacement:
. And if you swing a dead cat, you whack at least three PHP developers.I have to remember that phrase. Gruesome but funny.
Thanks for the info and views of PHP. It is nice to hear some positives about PHP as I mostly read about the security issues surrounding the multiple versions of PHP.
Like everything, PHP has had some security issues.
But most likely most of what you are reading comes down to stupid people not patching or stupid “developers” do copy pasta of code thy was poorly done in the first place.
