Is there a way to make an AIR app connect to a database over a network. I know it has a built in SQLLite but I need to connect to a database over a network. Is there anyway to do this? If not directly then maybe through the help of something else like Java.
Thanks!
The main challenge should not be the "over a network" requirement, but rather that you need an ActionScript driver for your DBMS. There are some third party libraries, e.g. asSql or Asql (both for MySQL), but I have no experience with either of them.
However, depending on your application, you might really want to consider to introduce some back-end encapsulating business logic and persistence, rather than having the AIR app talk to the remote DBMS directly. Especially for multi-user apps I would definitely discourage you from doing so.. If you want to introduce a back-end, the Java platform is certainly a good choice since there are two very good AMF3 implementations (BlazeDS and GraniteDS). I would also recommend to take a look at the Grails framework and especially the Grails Flex Plugin. There is a nice and informative article on InfoQ about Grails and Flex.
Related
Need help in developing an Enterprise application which involves hundreds of thousands of notifications and calls to server. Client has mandated to use Java/Springs stack. It has 3 portals involving like mobile, Institutes and Admin which depends on web services from server.
Which type of Database we should prefer?(It should support Hundreds of requests and Should support Geo-Location based queries)
Which application server we should prefer?
Which type of server side scripting we should prefer?
How about should I go with this?
You really should read the answers to this: https://gis.stackexchange.com/q/9809
One you know it or have anyone in your team who knows it. Otherwise WildFly seems pretty good.
Once again you must choose one you're comfortable with... and look at Thymeleaf.
If you are really starting something from the ground, you really get known the Service-oriented architecture and build your solution around it.
I'm designing an app which needs to have some collaboration functionality. So 1 to many users can edit certain attributes of an event they plan together. e.g. the main-admin can change the title, picture etc. while all admin-users could change the date for example.
I would like to get some ideas how one would approach this in the modern world. Are there fancy frameworks etc.
Q: Is the best way storing it centraly on some server or would some peer to peer data storage work?
Q: My gut-feeling is that a web-application would probably be the easiest way, where people work on the object stored on the server instead of trying to sync a local copy with some central repository.
Is this correct?
Q: Are there mobile frameworks which could do the syncing, locking etc for me?
Thank you for some hints and suggestions. I know the questions are a bit broad, but I'm looking for directions not finished solutions. Thank you.
Kind regards
Fred
Some thoughts:
1a) There is no "best" way without a metric for better/best. But yes, having a server is almost certainly simpler, which is probably part of 'best' for most of us.
1b) Actually, there is always a server. Even p2p systems have clients and servers, it's just that every node is both a server and a client.
2) Yes, a web app would certain give you a lot of plumbing for free, & would probably be fastest/cheapest route to a working app. An alternative would be an olde worlde client/server database. A shinier approach might be mobile apps which use a webservice to communicate with a central server.
3) databases do that. But actually, if you use a web app it's probably not hard.
Analogies:
Apart from web apps, version control systems do exactly what you've
just described. they even do offline editting and subsequent merging.
Straightforward CRUD applications against a database also do what
you've just described.
But perhaps I'm under-estimating what you mean by collaboration?
I have a project for a class which requires that if a database is used, options exist for the user to pick a database to use which could be of a different type. So while I can use e.g. MySQL for development, in the final version of the project, the user must be able to choose a database (Oracle, MySQL, SQLite, etc.) upon installation. What's the easiest way to go about this, if there is an easy way?
The language used is up to me as long as it's supported by the department's Linux machines, so it could be Java, PHP, Perl, etc. I've been researching and found info on ODBC, JDBC, and SQLJ (such as this) but I'm quite new to databases so I'm having a hard time figuring out what would be best for my needs. It's also possible there may not be a simple enough way to do this; the professor admitted he's not a database guy either and he seemed to think it would be easy without having a clear idea of what it would take.
This is for a web app, but it ought to be fairly straight forward, using for example HTML and Javascript on the client side and Java with a MySQL database on the server side. No mention has been made of frameworks so I think they're too much. I have the option of using Tomcat or Apache if necessary but the overall idea is to keep things simple, and everything used should be able to be installed/changed/configured with just user level access. So something like having to recompile PHP to use ODBC would be out, I think.
Within these limitations, what would be the best way (if any) to be able to interact with an arbitrary database?
The issue I think you will have here is that SQL is not truely standard. What I mean is that vendors (Oracle, MySQL etc) have included types and features that are not SQL standard in order to "tie you in" to their DB, such as Oracle's VARCHAR2 and so on.
When I was at university, my final year project was to create an application that allowed users to create relational databases using JDBC with a Java front-end.
The use of JDBC was very simple but the issue was finding enough SQL features/types that all the vendors have in common. So they could switch between them without any issues. A way round this is to implement modules to deal with vendor specific issues and write ways to translate between them. So for example you may develop a database for MySQL with lots of MySQL specific code in that, but then you may want to use Oracle and then there are issues, which you would need to resolve.
I would spend some time looking at what core SQL standard all the vendors implement and then code for these features. But I think the technology you use wouldn't be the issue but rather the SQL you create.
Hope this helps, apologies if its not helpful!
Well, you can go two ways (in Java):
You can develop your own classes to work with different databases and load their drivers in JDBC. This way you will create a data access layer for yourself, which takes some time.
You can use Hibernate (or other ORMs). This way Hibernate will take care of things for you and you only have to know how to use Hibernate. Learning Hibernate may take some time, but when you get used to it, it can be very useful for your future projects.
If you want to stick Java there Hibernate (which wouldn't require a framework). Hibernate is fairly easy to use. You write HQL which gets translated to the SQL needed for the database you're using.
Maybe use an object relational mapper (ORM) or database abstraction layer (DAL). They are designed to provide a standard API to multiple database backends, making it possible to switch between different backends with minimal or no changes to your code. In Python, for example, a popular ORM is SQLAlchemy, and an excellent DAL is the web2py DAL (it's part of the web2py framework but can be used as a standalone DAL outside the framework as well). There are many other options in other languages as well.
use a framework with database abstraction layer and orm . try symfony or rails
There are a lot of Object relational database frameworks, unless you prefer jdbc. For simple/small applications this should work fine.
I want to install a desktop application (on many stations - about 10-20) should access the SQL Server directly, no Services, and no server-DALs.
The application will be installed on a local network on about 10 machines, while one of them is a server.
When I will install the program I will set the connection string, and the applications will talk directly to the SQL server.
Is this a bad idea?
If yes, then how bad?
It is not necessarily a bad idea. If you won't need to scale then it's a valid approach.
What you are describing is often called a 2-tier client-server architecture.
You should probably encrypt the connection string in the config file (but this will only stop prying eyes, not someone intent on recovering your password). The other option is to use Windows authentication via a trusted connection, but you do lose the ability to connection pool, but that should not be an issue with 10 - 50 clients (ballpark).
Of course not.
What your describing is classic Client Server architecture, and around 50% of apps are still
built this way, according to a survey I saw recently.
Bob.
I have built plenty apps like that. I would suggest you build a DAL that is in the app itself so that if you ever need to separate data access and presentation layers, you can do so easily (plus there are other benefits like standardization of code, single place to change things, etc).
I don't see an issue with it as long as you are consistent and follow best practices.
If it's on your local network, go for it.
If it's over the internet, I'd create a web service.
Also note that there are plenty of off-the-shelf DALs (NHibernate, Entity Framework) so you don't need to roll your own, and the work just as well in client server architectures.
We have a relatively large application that is strongly tied into Firebird (stored procedures, views etc). We are now getting a lot of requests to support additional databases and we would also like to move a lot of the functionality from the client to the server.
Now seems like a good time to move to a 3(4) tier architecture. We have already looked at DataSnap 2009 and RemObjects SDK/DataAbstract. Both seem like they would do the job, but are there any advantages/disadvantages we should look out for? Are there any other frameworks that you could recommend?
Cheers,
Paul
I can recommend using the KBM Middleware components from Components4Developers. There is a bit of a learning curve but they are very flexible and hold up well under use in real world conditions.
Comment from a user (http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm)
Changing your application to Multi-Tiers with new framework (RM,DS,kbmMW, or what ever), will make a lot of changes in our application architecture, I recommended to go with this in future, but you can achieve the support for multi database, with other products like
UniDac from DevArt( Best components for database with direct connection).
AnyDac(from same Company who offer RemObjects.
SqlDirect(Has support for 9 MajorDB and also ODBC).
ZeosDB(Open source).
using one of the components above, will give you support for most major databases, beside it will not make you doig a lot of changes, and in some cases you just replace old database components with the new ones, and maybe change some of properties.
However, changing to Multi-tiers will not only make you only support more databases, but it will separate your business logic from presentation layer, therefore you can have more presentation layers for your application like web interface, or smart devices.
But the most important in the Multi-Tiers architecture, you will have a scalable system the grow more than what the database you are using can handle of connection, beside other benefits, like using other languages to write client applications.
In the process of moving to a multitier application you could consider using a transport protocol between the layers, which is language/technology independent (like webservices, (i think tha remobjects supports that)).
This could make a reimplementation of a layer simpler later (like if you later have to make a another version of the client-application in a browser/java/silverlight).
You can also investigate Midware http://www.overbyte.be/frame_index.html
For multi-tier architecture I also recommend to check out message-oriented middleware.
With message-oriented middleware, cross-language and cross-platform application integration can be implemented using the peer-to-peer or the publish/subscribe communication model. Messaging systems are loosely coupled, asynchronous and reliable. For example, they are core components in Java(tm) application servers such as JBoss.
For Firebird, I recently wrote a blog article on replacing Firebird database events, their limitations and ways to replace them with message-broker based solutions (which are available as open source):
Firebird Database Events and Message-oriented Middleware (part 1)
Firebird Database Events and Message-oriented Middleware
(part 2)
(disclaimer: I am a developer of Delphi and Free Pascal client libraries for open source message brokers).