Hi DB experts out there,
what do you SQL experts recommend to substitute a couple of MS Access databases by s.th. more modern like JAVA / Oracle or JAVA / mySQL?
The databases are small, not more than a few thousand records each. so there is no need for performance speed on the DB side.
But all of the MS Access stuff has complex forms with colors (for information purposes), details, nested sub-forms and a lot of nested queries.
Since MS Access is hard to debug and misses modern development tools as those in Eclipse I think about a redesign of the old stuff.
Said with other words, what is the best way to substitute especially forms?
Is Java Swing a good library to rebuild all the form stuff?
Or should I stay with the old stuff?
It depends how much time you want to spend on your new-design and who is using MS Access.
As you said, your MS Access db is very complex. If you want to replace this with mysql/oracle, it may take you long time to redesign the presentation layer (as you said, colors, details and so on.)
If you have time, you can design as totally new MVC framework project instead of old MS Access by using all new technologies. And you can learn a lot.
Not really a db question, the forms side of it is access as an application language not a database, whatever you choose you are looking at a good deal of work in Java if that's your application language choice.
This is a serious question: can it look like crap? Whatever tool you use, you'll probably want some kind of form-generation support (just to move things along). Form generation tools are all bad. It's a rule. But, they're bad in different ways. Also, having said that, I've never used one for Swing, as my desktop app forms were easy enough to build by hand. JFormDesigner looks feature rich and has some good-looking forms to boot (but because of the rule, we know you'll hate something about it).
If you want to stay with the old stuff, I recall that you used to be able to use access on the front end and connect to a different database server (SQL server). Depending on what year the access system is, you may have to replace immediate if (IIF) statements and do some other translation, but it would give you a database that makes troubleshooting queries a little better.
I guess only you can decide "why" you want to do this. If it not broke, then why fix it?
You can use source code control with Access if you want. I cannot say the debugging tools in Access are great, but then most Access applications tend to not have tons of code anyway. (much of the forms etc. work without code). And the report writer has received some upgrades that makes it even better – still one of the best around.
And Access 2010 has web like controls and effects now, so your screens can look like this:
Even the above round buttons and shadow effects where built using ONLY the tools inside of Access. So the new design options are quite extensive.
Same goes for the new navigation system you see on the left side. (no thrird party tools were used for above. So here is a SMALL sample screen shot of some new design options:
Also +1 for those here that pointed out that moving the data to MySql or some such is NOT the same as what you going to develop the application with.
Access is more of the development tool and part then that of the just some tables. The tables can be sent off to darn near any system like SQL server, MySql etc.
The problem and question and challenge is that of building the application part with the code and logic.
Speaking of SQL server, Access 2010 has baked in support for the cloud edition of SQL server. So Access works with SQL Azure. So if you looking for a cloud play, this setup works with Access.
Access also allows your tables to moved up to the new office 365. This is a great low cost way to get into cloud computing. And the office 365 setup allows Access to go "off line" mode. This means your laptops can go out, run the Access desktop application, and when they find some wi-fi or get back to the office, they sync their data. This is a true automatic "replication" model but works without any coding on the part of the Access developer.
And if you have SharePoint, then your tables and "off line" mode works with that.
Last but not least, Access now supports web publishing of your database. This works with office 365 or SharePoint.
This web publishing is true cloud computing with unlimited number of users. The only real limits are the capacity of Microsoft's computer farm (and it is really big one!).
Access forms when web published are converted into "zammel" .net forms (XAML). The Access code you write in the forms are converted to JavaScript and in fact this code runs "browser" side. (so you are building true multi-tier applications). Your table procedures you write inside of Access go up and run server side – even on office 365 (Not even .net developers can have code run so easy on office 365 servers!)
For those who not seen the web ability, in the following video, I switch to running the Access application 100% in a web browser at the half way point:
http://www.youtube.com/watch?v=AU4mH0jPntI
Such web applications built in Access don’t' require ActiveX or Silverlight, and as such they run fine on my iPad.
So, I am not really sure if one needs to get "caught" up on all of the new buzz words.
But if you looking to using office 365 and publish web forms, then Access does this now.
And if you looking to use the latest and greatest new edition of SQL Azure that runs up in the cloud, then again Access can be used.
And if you looking to use Access with SharePoint which is really popular, then again Access can be used.
And if you want "cool" shaded buttons with cool "hover" effects, then the new Access designer has these types of choices:
So there is tons of neat-o buzzy gee wiz bang things you can do with Access. Heck you can even build custom ribbons in Access now!
However, if you have a few basic forms that work just fine now? Why not just stick with what works?
I vote for KISS.
No real need to get caught up in the latest fads, but if such is your cup of tea, Access does have lots of that "new stuff" to play with these days.
Related
Community,
Could someone help me understand the basics of creating a website which calls MS Excel for data/calculations?
I have created a fairly robust Excel workbook which does thousands of calculations with the use of VBA macros. The ultimate goal is to be able to create a simple website for which users can visit to get results.
------ UPDATE -------
As I've learned, it is not possible to create a website which uses MS Excel as its calculations engine. Instead, one would need to build a stand-alone application which doesn't require MS Office. Basically, I have spent about 80 hours porting over a 300 hour Excel project onto a .NET desktop application. It was the best option for me. I researched & tried Java, C++, PHP, and other languages before I finally settled on .NET.
The toughest part is just figuring out how to store/retrieve/update the data necessary for your project. From there, transferring from VBA to .NET is fairly simple. The next steps for me will be to make a Web Application (with the use of Visual Studio 2012) that mirrors my desktop application. And finally, I'll just build the website. Once I'm done I will give an update for anyone out there who has built an Excel project which they'd like to take to the web.
Thanks - to all who've given advice.
website: not really. You need msoffice to run the sheet, so unless you manually execute the sheet previously so that the data is available for read (not execute) you can't do it with ms excel. You can do it with a programming language, depending on what you need and what you are familiar with you have many options VB(script) should be the simplest and PHP the most powerful of the most known. After just learn about the math specific issues and functions!
server: sure you can use that laptop, but it not only stores but also processes the page requests. Remember it should be set up properly with web serving software. Connecting by cable would be safe but the question is how reliable do you want it to be? A home connection and weak server might not be so reliable but it works fine for testing and small scenarios otherwise it's simpler to just hire a hosting solution. May cost from 15$ to 60$ for a basic site depending on what you need.
P.S.: there is an easy to use server software called xampp that runs smoothly on windows. It supports many languages and databases.
A1. Yes, a scripting language it's much slower and overall less capable, it depends on what you want to achieve if VB is enough.
A2. It is most powerful when it comes to calculations because it runs on the server and is versatile. for data storage i recommend databases but that can be complicated for you.
A3. No, you can't abandon HTML it is essential to web pages like a core structure.
new A1. Java is also powerful and more portable than php but with more issues since it runs client side. Jsp runs server side and is like php. Potatoes potAtoes. Start by choosing a language maybe but remember scripting languages are usually client side which means it depends on the users pc and the code is available to them.
new A2. Maybe not the best choice, but workable.
new A3. Excel speed is closer to php/server side languages i would recommend php for many reasons. Secure fast precise (no rounding) powerful many math functions might also have a few financial, not sure.
new A4. Yes, PHP and HTML work fine together but remember one runs on the server and HTML on the client.
new A5. Many on the web, also "php for dummies" as a book is a starting point.
new A6. You got me there, I'm not familiar with R.
There is web application, journalism related, that uses MySQL databases and presents a web based interface to users.
I want to build a iOS app that does a mobile interface as well. The UI is pretty easy and I have experience with that.
The problem is with the database, which I have no experience with.
I will be learning about databases and probably take the Coursera course on it. I am not asking you to teach me that. I just wanna know which technologies I should invest my time in over the next couple months.
My understanding so far is that the app should not talk to the database directly,
but rather there should be some one on the server talking to the database on behalf of the App.
This is the question and the part I want to understand clearly, so correct me if I am wrong.
I will have to write some sort of a unix program that runs on the server and talks to the db and then communicates back to app? how? using a web view? Using unix sockets to talk to the app? ssh? Which one is cool with Apple?
My preference for writing something like that on the server would be: python(have experience), java(have experience), and maybe ruby(no experience). I'd prefer to avoid scripting languages.
Are they ok? Which one is best suited? Also is this middle dude going to have to be on the same server that has the database or can be another machine on the internet(i'd prefer this, so i can put it on my own VPS and not have to screw up with the server machine)
This is similar to another question from tonight, but you're coming at it from a different angle.
In general terms, an iOS application that needs to be able to run in offline mode will need to have its own database. This means creating Core Data models to store all of the data required by the application. Internally this is stored in a SQLite database.
If you want to make an application that's online-only, it's somewhat easier since you won't need to worry about the Core Data part and can instead focus on building your service API. If you're familiar with Python then your best bet is Django to provide that layer. You'll need to implement a number of endpoints that can receive requests, translate that into the appropriate database calls, then render the result in a machine readable format.
Scripting languages are what power most back-ends even for massive scale systems. In most cases the database will be the bottleneck and not the language used to interface with it. Even Twitter stuck with Ruby until they hit tens of millions of active users, so unless you're at that level, don't worry about it.
For most applications, using HTTP as your transport mechanism and JSON as your encoding method is the way to go. It's very simple to construct, easy to consume, and fairly easy to read. There are probably a number of ways you might go about reading and writing this, but that's another question.
For small-scale applications where the number of users is measured in the hundreds then you can host the application and database on the same server. Even a modest VPS with 512MB of memory might do the job, though for heavier loads you might want to invest in a 1GB instance. It really depends on how often people are accessing your application and what the peak loads are like.
We would be in near future implementing a solution to modernize our iSeries applications
written as RPG programs with some stored procedures, and our preferred way is leveraging the latest and greatest of what Java has to offer in this space.
From googling and checking other questions here on STOVFlow, JTOpen seems to be the defacto
library/toolset which has worked for most and I was encouraged to see that Tomcat runs on an I-series box with out any issues.
With this as the background, I am thinking of the following as the high level sol arch
Install IBM JRE and use JTOpen's capabilities to invoke RPG Programs and in some cases directly call the stored procedures running on DB2
Have Tomcat host a modern web application built using Grails and other frameworks (Camel, Smooks) to provide an application logic layer which would fill any mediations, transformations required for the old functionality to be offered to the user from a browser
Questions-
If any one of you has been involved in such an exercise, please share the pitfalls with this approach
Is there a significant performance drop with respect to response times for the end user?
Would it be better to some how expose the JT400 code as web services and run the web app on a different machine altogether consuming these web services?
Be very careful with calling RPG from Java because RPG is not threadsafe without some changes.
When I was at COMMON, the best product I felt on the market was Profound UI. There are several others from a variety of vendors. Most of these products do not use Java. Java on the i tends to be slow. (There are things that can be done to make it faster, but native is always faster.) You'll pay the price for these products, but just imagine how much time it would take you to do this yourself. For the above, I was quoted in the $20+ thousand range. But like all i products prices vary greatly based on system.
To directly answer your questions:
I have been doing research on modernization as time allows, the products weren't quite there yet (at the time I looked) to use it for what we wanted to use it for (before COMMON 2011). Now it looks like it might work.
This really depends on your system. A newer system will have less problems than an older system. Web will always be slower than the green-screen. Hands-down entry people won't like it. Executives and younger people will love it.
Your slow point is running the business logic. It wouldn't matter which server the HTML is coming from.
I've found that for all practical purposes an AS/400 behaves like an AIX box seen from Java code, and you must use jt400 (jtOpen) to communicate with the AS/400 specific features like data queues, files etc. This works pretty well, but the slowness of invoking the JVM pressures Java based solutions to be long running.
Note also that QTEMP is generally unavailable as a mechanism to keep state due to the nature of prestarted jobs.
Under V6R1 Java 6 is available and runs pretty well in the "new technology" edition. You can then run almost all Java based solutions, including web servers like Jetty in it. Note that Java defaults to code page 819 when accessing IFS files directly. Windows clients using AS/400 as a network drive uses a compatible code page.
The application is vb.net front end and sql server express backend. The networks are always cabled LANs.
Installations are small with only a few users, none of whom would have any technical knowledge.
Very little technical support is ever called for and I'd like to keep it that way.
I don't know Java or Objective C or HTML/CSS/Javascript which as far as I can see seem to be the choices for smartphone development on Android, iphone or web based application
I want users to be able to access as much of the functionality of the application as possible for the least effort both in terms of coding and acquiring new skills on my part.
I don't know where to start or which would provide the easiest path.
I don't know how to make the database available to smartphones whilst keeping it physically secure in a small office.
If all things were equal I'd probably learn towards HTML/CSS?Javascript as it seems to be the most widely applicable.
On the other hand maybe I should wait for win phone 7?
To reach the largest number of users in a device independent manner then delivery via browser is going to give you the best results for the least effort.
If you have designed you existing application with a Data Access Layer, a Business Rules Layer and a User Interface layer, this may be as simple as creating an ASP.NET UI for mobile/internet/intranet users.
If your appliciaction is not designed this way, then my approach would be to seperate out the code in you existing into these three layers, or at the very least seperate the UI layer out of the existing code. Then it just a matter of implementing a UI layer for each access method you plan to use.
That way you end up with a lot less code to maintain, and when the businees rules or backend data changes you only have to do the change in one place for all you User Interfaces.
Well, .NET Compact Framework is already avaialbe on WinMobile, so you defenitely should give it a try if you're free to choose which mobile OS to target.
If not, I suppose that for task like this it would really be better to use web interface. If you don't now HTML/CSS/JS - as for me it's not a problem but a great chance to learn new interesting trendy things! :)
I would go with a simple html app designed for a mobile screen.
Android or iphone will only get a % of your users. If you want to get them all, you would need to write in both (and then blackberry and winmo are SOL).
So without seeing the application, it is very hard to know how much work converting vn.net to something you can get at from a web browser would be... but I don't think it would be much worse than a port to android or iphone, and it will allow a much bigger market to view.
Either way, you will need to learn something new. Learning is good though, right?
Alright, so I am a compsci college student who, being in college, has not branched out towards a certain specialization yet. I have been programming since I was a young teenager, certainly know my stuff - well versed in about eight different languages as well as compsci theory, etc. In addition, I have about four years of web programming (PHP mainly) behind me, having started freelance work in that area since web 2.0 became hot.
My summer job now as an intern of sorts is to write an application for an industrial, not software-related startup. This application will be used to manage production lines and logistics flow. I have chosen Java for my language because I don't want to shoot myself in the foot.
I am well-versed in the syntax of Java, in its data structures, language theory, and such, but I have absolutely no idea where to start. I can picture the program perfectly in my mind, I understand the problem clearly and got the solution's theory nailed. Namely, I have no idea what libraries to use, and am scared that they won't be well documented.
Here are some general outlines of what I'm going to make:
Two applications, one server and one
client (of which there will be many
copies).
The server and clients obviously will
communicate via (I don't know).
Both the server and the client
software will have GUIs.
The server software will have to
query a MySQL database.
The client software must be 'live' in
the sense that the GUI updates when a
change is made to the database. This
is one of the reasons why it can't be
a web application.
I'm not even sure if a framework is right for me or not. I've used MVC tons of times in my web freelance work, but I dont know how that will translate for desktop applications.
In short, I'm looking for the right libraries for the job, as well as advice on whether or not I should use a framework (and if so, which). Thanks.
This is a summer intern job? To be honest, this sounds more like a major project if you ask me. You say the start-up is not software related? Who came up with this idea? Do they have any idea of the (huge) scope that something like this might actually entail?
The business of software development is something quite different to language syntax and libraries. It's about requirements gathering, defining a spec, writing code, ensuring quality of that code, having it tested and so on. These are not things an intern should reasonably be expected to pick up. For something like this you should be under more experienced supervision, someone you can learn from, someone who has done this before.
That being said, unless there's a really good reason, I would probably do such a thing as a Website rather than a desktop app. Desktop apps are a lot more complicated in many ways. You need to code both a client and a server. Communication is a bit trickier. You have to worry about the issue of maintaining state in multiple applications, how to handle updates being pushed around and so on.
In short, it's a big job. Even a Web site is a big job but a lot of these issues go away. You could do this with Java. I've certainly coded my fair share of Java Websites but PHP might be a far simpler bet.
Also, desktop development on Java is, well, torture. Swing is (imho) tried and true but also incredibly painful to develop in. Other desktop libraries (eg Netbeans RCP, Eclipse SWT) are more modern but have other idiosyncrasies.
Desktop remoting libraries include things like Spring remoting, even Web services and other things like Burlap. For the server side, I'd be using either Tomcat or an application server (Glassfish is my preferred choice), servlets and Spring. Persistence can be done via Hibernate or Ibatis (or lots of other options).
But honestly, the desktop option is so much more complex than a Web-based one. You'd probably get a lot more done faster using PHP + jQuery + MySQL.
If you are doing this keep it as absolutely simple as possible. Try to define the absolute minimum you need to initially deliver and do that. Once someone has that they'll then have a better idea of what works for them and what doesn't. Basically it's easier to refine something that already exists vs define something that doesn't.
I recommend that you only build a web application. A web application can be 'live' in the sense you are describing it by using AJAX. It would be much easier to build just one thing. If you also want to have a rich client, then you need to build the UI in a technology you are not familiar with (like Swing or SWT) and design/implement the communication mechanism.
Have a look at Hibernate (ORM tool) and Spring (IoC framework). They have a somehow steep learning curve, but they will make your life easier at the long run. For the UI part perhaps JSF is easier for a beginner.
As a last note, I think you have an over-ambitious plan. What you are describing is not an easy project and requires expertise with a lot of technologies. Do not try to do everything in one shot.
Java Desktop 6 (JRE)
JDBC (built-in in any JRE)
MySQL JDBC drivers (freely downloadable)
for communication you have several choices: RMI (built-in) however this days I recommend
learning something like Java Web Services (JAX-RS)
Libraries?
JDBC for the database. You may want to look at ORM mechanisms like Hibernate
I would recommend the Apache Commons libraries for all your utility work (handling files, IO etc.). There's a lot of stuff there to save you reinventing the wheel.
A standard logging framework like Log4j will allow you to log in lots of different ways, filter your logs and plug into monitoring solutions easily.
You don't say whether browser-based solutions are acceptable for the client/server GUI, and that decision will drive a lot of the further architecture.
If you're looking at browser-based solutions, then I would advise a grounding in servlets regardless of any framework you ultimately choose (no doubt a lot will be recommended here).
By this stage it's getting to be a major project. Perhaps you need to concentrate on getting the fundamentals (client/server functionality) working, and worry about the GUI later. Otherwise it's a huge amount of work (and GUI work can draw an enormous amount of time).
Just one nitpicking:
Both the server and the client software will have GUIs.
I advice you to have a headless (in awt parlance) server, with an administration GUI, not a GUI-server.
Well this can go as wild as you can think of or you can go and do KISS.
If you would like something that is really simple (as in not using any frameworks):
* In the server side you can use RMI. This server side will use plain JDBC to connect to your MySQL database. But some said that this is kind of old, so if you want to get funky you can try JAX-RS which can return a JSON objects/XML to your client.
* Your client can be made using Swing (assuming you are developing desktop) or Servlet + JSP (assuming you are developing webapp) and connect to your server by calling the RMI objects/JSON objects/XML that is exposed by the server.
If you would like to get nasty which will help you in terms of code maintainability you might want to plug-in Spring + Hibernate into this application.
Good luck!