very urgent

[nehaa]

what we need to do for making an application which can be accessed on LAN by many users
application is "daily report of an organisation"

thanku:)

[dswastik]

If its a desktop based application you can think of RMI and if its a web based application you can think of servlet/jsp.

[vishnu69]

hi, i need sample code, i want to run client ,server on one system, and send the output to multi systems.

the data sent by server need to be displayed on the multi clients.,,and i dont want to run client program on every machine..only on server machine itself i want to run client program.

[vishnu69]

Hope multi casting can be used neha,,

package udp;

import java.net.*;
import java.io.*;

public class MulticastSender {
public static void main(String[] args) {
InetAddress ia = null;
int port = 0;
String s = "Here's some n";
byte[] data = new byte[s.length()];

// read address from the command line
try {
try {
ia = InetAddress.getByName(args[0]);
} catch (UnknownHostException e) {
System.err.println(args[0] + " is not a valid address");
System.exit(1);
}
port = Integer.parseInt(args[1]);
} catch (Exception e) {
System.err.println(e);
System.err.println("Usage: java MulticastSender multicastaddress port");
System.exit(1);
}

data = s.getBytes();
DatagramPacket dp = new DatagramPacket(data, data.length, ia, port);

try {
MulticastSocket ms = new MulticastSocket();

// you can try to use different TTL value here for ms.
//ms.setTimeToLive(16);

ms.joinGroup(ia);
for(int i=1; i<10; i++)
ms.send(dp);
ms.leaveGroup(ia);
ms.close();
} catch (SocketException e) {
System.err.println(e);
} catch (IOException e) {
System.err.println(e);
}
}
}



package mulcast;

import java.io.IOException;
import java.net.DatagramPacket;
import java.net.InetAddress;
import java.util.Date;

public class MulticastServer {
public static void main(String[] args) throws java.io.IOException {
new MulticastServerThread().start();
new QuoteServerThread().start();
}
}

class MulticastServerThread extends QuoteServerThread {

private long FIVE_SECONDS = 5000;

public MulticastServerThread() throws IOException {
super("MulticastServerThread");
}

public void run() {
while (moreQuotes) {
try {
byte[] buf = new byte[256];
System.out.println("<<>>> MulticastServerThread<<>> run");
// construct quote
String dString = null;
if (in == null) {
dString = new Date().toString();
System.out.println("dString::" + dString);
} else
dString = getNextQuote();
buf = dString.getBytes();

// send it
InetAddress group = InetAddress.getByName("230.0.0.2");
System.out.println("<<<groupgroup >>>" + group);
DatagramPacket packet = new DatagramPacket(buf, buf.length,
group, 4446);
socket.send(packet);

// sleep for a while
try {
sleep((long) (Math.random() * FIVE_SECONDS));
} catch (InterruptedException e) {
}
} catch (IOException e) {
e.printStackTrace();
moreQuotes = false;
}
}
socket.close();
}
}

[Steve11235]

Hold on! You don't seem to know how you even want to present this report. Your business people might greatly prefer the contents to be a delimited file (I prefer using TAB rather than commas and quotes; it a lot easier). They would download the file using a Web browser and open it using Excel. You could also present the report as a Web page, e-mail a PDF file, or you could create a custom application to display the data. Until you decide all that, there is no point in talking about TCP versus UDP (use TCP, it's more reliable).

If you want to use a client (instead of e-mail), let the client pick up the report from the server. Pushing to a client is much more complicated. You publish the report once on the server, and clients pick up the report when they are ready. You can date each report, so clients can choose to retrieve an older version.

Do *not* publish the report each time a client requests it. If you do, two people will end up with different versions of the report as the data changes, and they will claim the report is no good!

If you want to use a custom client, consider publishing the report as an XML document. Java can easily consume XML and then format it for display, and other application, such as a Web browser, can as well.

If you go this route, place the report file on a Web server. Have the Java client download the file using HTTP. This is a more flexible solution that reading from a file share.

[nehaa]

THANKS FOR YOUR CONSIDERATION

Let me explain u my problem:-
i have reports in the form of excel sheets.I want to make a software for it with JAVA as frontend and ms-access as backend.I want this s/w to work on LAN.I also want that if 1 user is doin some changes then other users can have only-read access means simuntaneously more than 1 user should not have write access.I want users should use URL to access my s/w regarding reports.
thanku :)

Hold on! You don't seem to know how you even want to present this report. Your business people might greatly prefer the contents to be a delimited file (I prefer using TAB rather than commas and quotes; it a lot easier). They would download the file using a Web browser and open it using Excel. You could also present the report as a Web page, e-mail a PDF file, or you could create a custom application to display the data. Until you decide all that, there is no point in talking about TCP versus UDP (use TCP, it's more reliable).

If you want to use a client (instead of e-mail), let the client pick up the report from the server. Pushing to a client is much more complicated. You publish the report once on the server, and clients pick up the report when they are ready. You can date each report, so clients can choose to retrieve an older version.

Do *not* publish the report each time a client requests it. If you do, two people will end up with different versions of the report as the data changes, and they will claim the report is no good!

If you want to use a custom client, consider publishing the report as an XML document. Java can easily consume XML and then format it for display, and other application, such as a Web browser, can as well.

If you go this route, place the report file on a Web server. Have the Java client download the file using HTTP. This is a more flexible solution that reading from a file share.

[DarrylBurke]

How To Ask Questions The Smart Way

[Steve11235]

I understand.

First, do *not* use Access. You will end up hating yourself for doing it. M$ SQL Server is the obvious alternative, if it is available, or any other database server that is already running and available to you. MySQL is a good, free alternative.

Excel accepts TAB delimited files very well. This basically a CSV (comma separated values) file, except it uses TAB instead of comma, and it does not require you to place character data in quotes. It is much easier to generate.

One way to distribute reports is simply to generate the output to a file and then e-mail it to the recipients. I have used that approach in the past, and business people like it. They get their reports wherever they are, and they don't have to hunt around for them.

As far as updating your database, how are you allowing your users to do that? You can use Access to update a database using linked tables, and multiple users can work at the same time. If you want to use a Java program, you can create a client application or a Web application. Which is best depends on the resources available to you and your experience.

[nehaa]

THANKS FOR YOUR VALUABLE SUGGESTION

We have to use MS Access because of company's restrictions.
As far as updating is concerned ,actually we are generating only software for users.Users will use that software to fill data in that software for generating reports.
Different pages of the report are filled by different users.We will provide functionality to save the data entered by users in MS Access database and if they find that they enter wrong data then they can edit that and then edited data will be stored in the database.
Users want to access Software on LAN using URL.
These reports are generated on daily basis.User must also have the functionality to access reports of any date.
Waiting for your reply.

THANKYOU

[fishtoprecords]

If its a desktop based application you can think of RMI and if its a web based application you can think of servlet/jsp.

I can't think of any reason to ever use RMI. It was needed back with Java 1.0 back in 1996. Its no longer a good idea.

Using RMI causes far too much interdependances between the client and server code. It becomes a bug farm. Don't do it.

Send text messages.

[nehaa]

I can't think of any reason to ever use RMI. It was needed back with Java 1.0 back in 1996. Its no longer a good idea.

Using RMI causes far too much interdependances between the client and server code. It becomes a bug farm. Don't do it.

Send text messages.

Thankyou...Kindly suggest me another option..
Thanks in advance.

[Steve11235]

Different users enter data that is stored in a database. The users can add entries or update existing entries. Different users enter different portions of the data.

They want to use M$ Access and to get at the database using the LAN.

Been there, done that. The users created an Access database and Access forms to enter the data and run the reports. Worked great, except that, every two months, the database file would become corrupt because someone closed a form the wrong way.

If they have to use Access, then let them. They don't need Java to update an Access database. That's what Access is for.

The *only* problem with doing the whole thing in Access is the database is *not* designed to be used by more than one person at a time.

Moving the database to SQL Server solves the problem. The users can use Access to update the data and run their reports. They can connect to the database using whatever M$ calls their database access middleware these days. (Anyone remember RDO? What was it called before that?) Or, they can use ODBC.

The only way to use an Access database safely would be to create a Web application with a form for each type of data that needs to be maintained. The servlet would create *just one* connection to the Access database and synchronize its use among the different threads.

If you must go this route, you are probably better off using ASP.NET, since I doubt Access supports JDBC.

That's a lot of work to create a really poor solution that will probably be unreliable, anyway.

Talk to the business. Tell them they can use Access to enter the data and do reporting, but the database should be SQL Server, so they don't lose their data. Tell them the WILL lose their data at regular intervals using Access database.

[fishtoprecords]

Thankyou...Kindly suggest me another option..

I did:

Send text messages.

The text can be any format you like, even XML