Client/Server Application with Database RRS feed

  • Question

  • I'm going to be building a client/server type of application and would like to use .NET technology - but am a little unsure about the architecture/which technologies to use.  Let me describe the application for you:
    The server side program must be able to parse web pages for certain data and store this data into a website.  The server must do this every sunday night at 2am to archive that week's data.  From what I understand, I will able to do this using HttpWebRequest and WebResponse and have found a tutorial on this. I would also like to archive the data using a SQLServer 2005 database, which will run on the same server as the parsing application. 

    The client side program must be able to connect to the server and run queries on the archived data, display the data to the user, and map some of the data using  The server must be able to support up to ~300 simultaneous connections.  I have done some reseach on socket programming for client/server applications and I understand how to send data/text back and forth, but I do not understand how I would go about executing database queries on the server.  Any help on how I should go about this architecture would be appreciated.

    Monday, June 19, 2006 6:30 PM

All replies

  • Mike


    There are two applications here on batch application to get data into the database and the other for reporting.

    Regarding the batch mode one – you can consider using SQL Server's Integration Services (SSIS – formerly ETL).

    Regarding the number of users are you talking about 300 concurrent users or a total of 300 users - if you really expect 300 users hitting the DB simultaneously I doubt that a single server would suffice. Since (as you describe it) the data is mostly read-only (with daily batch-updates)  it shouldn't be too much of a problem to  have multiple copies of it and scale the solution. Also if you only query the data you may consider exposing the queries as web-services directly from the database (again this is assuming you don't have any real business logic)


    Saturday, June 24, 2006 4:04 AM