November 2, 2005 at 3:52 am
I'm developing a client db aplication for sqlserver in delphi. i have to come up with a way to refresh the recordsets that i curently use in the aplication IF any changes ocurred to them on the server.
For example:
im executing a stored procedure and stare at the result (grid) for a lot of time. if any data changed while im staring at the grid, i want to be able to see the changes. lets say i know when the data has changed(on the server) but i need to send a notification to all conected users on that server. net send wont work because i cant catch it from the application, im still searching for a different way to notify the clients that some changes were made and they need to refresh.
Second one: the aplication is a big one, with lots of forms, controls, grids. I am curious if there is any software which will help us test si automatically. I never worked with this kind of software, but i imagine that it sends messages directly to our aplication, because manually testing it takes a lot o time, and many of the old tests are not redone...
November 2, 2005 at 7:37 am
If you're using VB6 to write this application, you might want to use the Winsock control to communicate between the server and the client.
Once the client connects to the server, the server only needs to use the SendData function to send the data to the clients, and then the client uses the DataArrival event to respond to it. Hope this helps!
November 2, 2005 at 7:42 am
Whoops! I glossed over the part where you said you were using Delphi. You can still use sockets in Delphi, but this link might be helpful to you instead:
November 2, 2005 at 1:09 pm
G'day,
re: how to test the monster: Take a look at Mercury Interactive's web site. Their LoadRunner and WinRunner tools are ideal for what you describe. I have used their software to verify that a system can handle 2 million concurrent users. They provide solid tech support, as well as consulting support to get you up and running. No, I do not own any stock in the firm.
re: how to force the client to update: Can your clients run a periodic poll in a background thread? I have used a single table in the past that contained two columns: TableName and LastUpdateTime. The table has one row for each table in the database. A simple trigger on each table updates the status table on every insert/update/delete. In this approach, the client simply checks the status table periodically and refreshes itself when required.
It worked well for me and allowed my servers to remain relatively stateless and disconnected from the client. If a client dropped out, or had poor connections the system just kept on plugging away. No sockets to handle, really quite simple all around. The possible gotch with this approach is that the status table *may* become a bottleneck. You will need to consider locking issues carefully.
Random thoughts. Hopefully some of them make sense.
Wayne
November 2, 2005 at 2:09 pm
thank you both for your posts. I'm sure that its gonna work in both ways, but i was HOPING that maybe im missing an easier way. I imagined that there is a way to redirect a raiseerror or print to a given user or userid... Even if the sockets posibility sounds more profesional, it scares me the idea of writing an extended procedure in c to use them.
I guess i will have to use the second idea, even if it will require some aditional overhead on the server.
I will also take a look at the software that you recomanded wayne.
Thank You
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply