I need to write web application using java webgui Vaadin Framework which will be real-time updated with new records inserted to MsSQL database by MsWin2k8R2 NPS.
Since NPS stores logs to files and/or DB, I prefer DB, but I'd like to know how my java program can be notified by SQL server when NPS server inserts data to database and then re-fetch or extract from SQL server notification and display it in browser.
I already have Java<->Ms SQL connection established.
What I already know:
SqlDependency class could be used but it is only for .NET and I'm working in Java
SQL Server Service Broker - this is some kind of a feature in SQL Server which can be used for this but I currently don't understand correctly how to do it and what it really is
SQL Extended Events - same as above
SQL Notifications - same as above
SQL CRL Triggers - trigger written in C++, C# or maybe in Java which is executed on specified situation but this is done synchronously and will slow down whole operation
Now. I've found this post:
https://stackoverflow.com/a/534831/1235977
I would suggest having a trigger on the table that calls the SQL Server Service Broker, that then (asynchronously) executes a CLR stored procedure that does all your work in a different thread.
But I don't know how to do this.
So what I need is:
Simple table in SQL Server which when inserted data into will notify my Java program somehow. It can be using REST web services, JMS or anything what is language independent.
Please provide step by step examples/solutions.
You can use trigger functionality of SQL.
There is a solution:
SQL Triggrer for table that calls Stored procedure
The stored procedure calls some c# code that will REST service by http.
Your back-end will process http requestes from stored proc.
Related
I have a central SQL server which can be INSERTED INTO and SELECTED from via PHP. However I have built a Java application which I hope to be able to Insert and select stuff in the SQL table with that I have hosted on a web server.
How would I go about doing this? I don't really want to have the root password with JDBC in the source code as even if it is obfuscating it can easily be deobfuscated and then the user has direct access to the database.
Someone said to me that I should use an API but I don't see how I will be able to interact with the database by doing this.
If you already have a PHP application running server side that handles database interaction; I recommend letting that handle if for you.
Write an API in PHP that handles all of the database interactions and send requests to that API from your java application. (I'd probably have the users create an authorization token to pass along to the API as well so you can track who is using your API and limit access).
Your application can then send HTTP(s) POST/GET/etc requests to your PHP that will then handle the database interactions and return the results. Your database username and password will be kept on your server and your application will not need to know them.
If you don't want to rely on a backend service and want your client application to interact directly with the database... You'll probably have to include a username and password in the code. BUT I'd create a separate user in the database with limited accessibility that could be removed anytime you suspect abuse.
I have an application connected to a database on a Microsoft SQL Server, I need to listen to any changes (create and update mainly) done on one of the tables and trigger an action in java in that application.
Is there any way to do so?
It depends how quickly you need to react to the change on the table and what access you have on the database.
If you can tolerate couple of seconds delay I would query (every couple of seconds) table information from system tables for last updated information. This will only work if you have access to system tables.
Try googling "microsoft sql table get last updated information", there are quite a few examples which might help your particular case.
I am making an application similar to that of apps such as pay by phone and paymobile, which are apps used to pay for parking instead of using a parking meter and having to display a ticket in your vehicle.
I need to start with the back-end (the database) and was wondering if SQL would be appropriate for this app.
As SQLite is stored on the system (the Database) there will be data such parking details and payment details.
Will I be able to send this data to say my laptop which will act as the server for the traffic wardens device to check number plates?
Or would I have to use a sql software that is not on the applications itself?
Any thoughts and suggestions would be much appreciated :D
SQL is perfect for back end database needs. You can various flavors of SQL like Oracle or MySQL on the back end. As far as the application data being sent to the server (your backend laptop), that will be taken care by the application level programming. For android, there are various ways to send data, using the native class AsyncTask or using third party libraries like Retrofit and Volley. You need to take a decision depending on the architecture of your app.
Try this
Create database on your server
Create Web API like .Net MVC on your server
Create connection between your Web API and your database
In your mobile app you can use webservice to get our put your data to database
You can encyrpt your data on your database to more safety
do not use SQLite , because it is unsafe to keep your important data.
I was developing my application on windows mobile using sql server compact successfully, what I need now does this sql server compact is supported on android sdk ? One thing I want to use sql server compact on android instead of sql lite because of the database engine can read data in multiple thread / multiple connectivity at the same time when performing table lookup while the other connection is reading table. I cannot perform this action on sqllite, sqllite use file locking on its engine.
Does anyone facing this kind of problem like I did ?
In it's current form, sql server can't yet be supported by Android, which is why there is sql lite.
Our customer has a client/server application based on mdb database (microsoft access) and he'd like to expose part of data via his web site (deployed in java).
What is the best way to achieve it?
I need a place to start (for example web service, spring integration, mule, service mix).
If the web server is currently located on your office LAN, and the access front end applications can use/see the folder where the back end mdb file resides (we're talking windows networking here), then in theory you could expose some of this data to the web server if web server loads and usage rates are not going to be too high.
In the case that the server is not going to be on the same Office Network, then an often used an reasonable solution is to simply move the back end data out of access and move it into some database server such as SQL server, or mySQL. When you do this, then both the access application (front end part) thus continue to run and function as before. And now also the web site can also share that data. This so called upsizing process of access data is not hard to do, but you want a competent access developer that knows both SQL server and access, and has done upsize many times. If the developer done this many times then it not a lot of work in most cases to move the data out to a server and keep the existing code investment.
So your choices are to keep the access code and database as is, but simply move the data out of access to a server based system. As noted the other alternative is in the case that if your web server is attached to the same network where access data resides, then in theory would be a simple matter to place the access backend data on the same server as the web server. This setup would allow both the locally users on the Office Network, and the web server to share and utilize the data in the access backend file.
Another alternative is of course is to have access to connect to a database server your utilizing on the web system, such as MySQL of SQL server. Since access can connect to the database server in this fashion, then again it is theory possible to shuffle data at predetermined times, or even during use to pull data down that's been gathered from the web site into the access application. So you keep Access as is, but connect it to the web part that gathers needed data.
Which of the alternative above choices above makes sense will depend on your particular set of circumstances.
To really throw a wrench into this mix, access for 2010 can build scalable cloud computing systems where the data is based either on Azure SQL or even 100% web based if you have SharePoint. In fact when you publish an access database to sharepoint now the result is .net XAML (zammel) forms and a scalable system in terms of users. In the following video you'll say that the halfway point I switch to running the access application entirely in a browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
To do the above access web development, you'll be using SharePoint. However, if your organization does have SharePoint now then this could be a reasonable possibility for you.
You can connect to your ACCESS database with Java through JDBC-ODBC Bridge.
The steps to do this would be:
In your server (the one hosting your Java Web Application) create an ODBC entry pointing to your ACCESS file. Name it mdbodbcaccess.
Then connect to that ODBC entry from Java using JDBC.
Something like this:
//
// points to the entry you've just created
//
Connection conn = DriverManager.getConnection("jdbc:odbc:mdbodbcaccess");
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("select f1, f2 from table");
while (rs.next()) {
// iterate your resultset and do something with it
System.out.println(rs.getString("f1"));
}
rs.close();
st.close();
conn.close();
Alternatively, you might want to use pooled connections from your Application Server.
I believe that you are a little bit disappointed.
MDB is Message Driven Bean. It is not database. It is a way to listen to JMS destination and perform some action driven by JMS messages. The data already must be saved somewhere in DB. If they use MDB it is a Java EE application.
Now about the site. Which technologies are used for site? If it is java based technologies your life is easier because the site is a Java EE application too. In this case you actually have 2 Java EE applications. If all these correct you can
merge them. In this case you can just call the "mdb based application" from the back end of the web site.
Alternatively you can call one application from another. Perform remote EJB call or expose some of the API as a web service and call it. Or even connect to the queue of "mdb application" from site and send messages.
If site is not written in Java use web services or connect to queue.
Generally you have a lot of possibilities. But it is hard to recommend something specific without additional details. I hope that this answer helped you a little bit. If you need more help please provided details.