|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Hi. I have a complex problem at work. I have made a script that manages a database and performs certain tasks. Easy enough. The difficulty is that mIRC is living on a Windows 2008 Server and I need three (or more) people to be able to access the same instance of mIRC over the internet using the remote desktop client. When one instance modifies the database, I need it to update in all of the other instances so that everybody is working with the same information. Does anyone have any suggestions as to how this can be accomplished? I considered writing a server, and having all the clients notify the server when it makes a change, which in turn will notify the other clients, which can then reload the database. However, I'm not convinced the IT guys will let me do this! Thanks in advance
|
|
|
|
Joined: Jun 2003
Posts: 81
Babel fish
|
Babel fish
Joined: Jun 2003
Posts: 81 |
Well, that sounds quite cumbersome. But if you really need to keep local copies of the database just use existing infrastructure for the communication, a small HTML page would be enough to do the work.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Sounds to me like you've grown beyond mIRC. You should rewrite this as a web application over HTTP or something. Unless the tasks are IRC related.
That said, you should never be storing your db entirely on the client side. There is your problem. If you want clients to stay in sync, they should be using a centralized database that they all share over the network, they should not be synchronizing their own databases, that's just a headache in any language / implementation.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Sorry if I wasn't clear; the database is stored on the server and any changes made on any of the three mirc instances update the database file just fine. The difficulty is that when somebody is viewing the database in mirc and somebody else makes a change to the database file, the change isn't reflected in mirc for the first person. The db is displayed in an @window. What I need is for changes to the database file to be updated in all clients that currently have it open in mirc. Monitoring the file for changes with a timer and $crc and then reloading the entire thing seems like overkill. I realise there may be better things than mirc for this, but mirc is what I know and it's very quick to write up a script. I'm writing some scripts to assist in the repetitive tasks I do in my day job. Cheers
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
Are you trying to view the entire database at once? Or just one table at a time? If you're only looking at one table, then having a timer to just refresh your data may be enough depending on your needs and how large the table actually is.
If you don't mind adjusting your table, then add a last modified field to it (and a last modified by field is usually also good) and then use a SQL (or whatever database structure you're using) query/stored procedure to check for any rows that have updated since your last check. This tends to be low overhead on the server even with checking regularly. Then, you can just load in only those changed rows instead of the entire table.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Jun 2003
Posts: 81
Babel fish
|
Babel fish
Joined: Jun 2003
Posts: 81 |
But in your first post you said everyone would work with the same mIRC instance. Do you mean they all launch it from the same network share?
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
Are you trying to view the entire database at once? Or just one table at a time? If you're only looking at one table, then having a timer to just refresh your data may be enough depending on your needs and how large the table actually is.
If you don't mind adjusting your table, then add a last modified field to it (and a last modified by field is usually also good) and then use a SQL (or whatever database structure you're using) query/stored procedure to check for any rows that have updated since your last check. This tends to be low overhead on the server even with checking regularly. Then, you can just load in only those changed rows instead of the entire table. It's just a text file with a list of clients and related information, separated by tabs. I can quite easily modify it if required. I thought about adding a unique id to each entry and somehow sending a signal to the other clients with a list of the ids that have changed rather than reloading the whole thing. There's literally about 80 items at the moment and it shouldn't get much bigger, as items are deleted too. But in your first post you said everyone would work with the same mIRC instance. Do you mean they all launch it from the same network share? Yes, they launch it from the same mapped network drive. Three people on three different computers, log onto three different terminal server sessions, and launch the same installation of mirc from a mapped network drive. Any of those people can update the file at any time, but the changes won't be updated in the @window for the other people who are also logged on. The other option I have, but that I don't want to go down, is that I could make it so only one person can access the database at once. I'd prefer not to do this if it can be helped. ------ Brainwave!! I could write all of the amendments to a changes.txt file, and make sure that the script reads and updates all of those modifications in the db before making any changes of its own. It doesn't necessarily need to be updated in real time. Does that sound good? Can anyone foresee any problems with that?
Last edited by hixxy; 16/03/12 12:40 PM.
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
Could you use a "coordination" table (or even a separate .txt or .ini file), that would be updated by whichever mIRC makes changes, to record that changes have been made (and which tables were updated, if necessary)? The other instances of mIRC could monitor that table/file periodically and thus, know when (and what) they need to update. The other mIRC's could then update the same file to indicate that they have read the new data. You could even use the information in the file to create a sync tab on the client's screen.
Also, I've never used DDE in mIRC, but maybe it would be suitable here to notify the other mIRC's that something has changed.
-genius_at_work
|
|
|
|
Joined: Jun 2003
Posts: 81
Babel fish
|
Babel fish
Joined: Jun 2003
Posts: 81 |
I could write all of the amendments to a changes.txt file, and make sure that the script reads and updates all of those modifications in the db before making any changes of its own. It doesn't necessarily need to be updated in real time.
Does that sound good? Can anyone foresee any problems with that? Compared to reloading 80 lines of a text file this will hardly be worth it. If you're worried about the efficiency of this design the easiest thing you should do is switch to a more advanced database system anyway.
Last edited by TRT; 16/03/12 03:16 PM.
|
|
|
|
Joined: Jan 2004
Posts: 1,361
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,361 |
If you're polling I think checking the $file().mtime would be sufficient. If you don't want to poll and want to keep it all in mirc, you can have all the instances listen on a different port (which will be written to a file), and then use sockets to notify the other instances when necessary.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I don't see how this is any different from three webpages visiting a page and then one client changes the page. The other two clients won't see the update until they refresh the page in their browser.
So, following that same mentality, you would want to do just that, and have your clients "refresh the page", or in this case, the window. You could expect it to be done manually, or you could do it automatically via timer. I don't see why that is overkill. Indeed, just like HTTP has E-Tags or Cache-control headers, you would use some basic checks to verify that the db was modified between retrievals so that you don't have to download the entire thing at each timer cycle. Using $crc/$md5/$sha1 would work fine, as would a timestamp on your db as suggested.
Unless your db is extremely large, I would suggest just downloading the whole thing. Dealing with delta changesets is complicated and *that* would likely be overkill.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
] Compared to reloading 80 lines of a text file this will hardly be worth it. If you're worried about the efficiency of this design the easiest thing you should do is switch to a more advanced database system anyway. It could work. Reloading the whole thing could interrupt what the user is doing but I'll try it. If you're polling I think checking the $file().mtime would be sufficient. If you don't want to poll and want to keep it all in mirc, you can have all the instances listen on a different port (which will be written to a file), and then use sockets to notify the other instances when necessary. The difficulty is that all three terminal server sessions are running the same installation of mirc, so how would each know which port to listen on? I don't see how this is any different from three webpages visiting a page and then one client changes the page. The other two clients won't see the update until they refresh the page in their browser.
So, following that same mentality, you would want to do just that, and have your clients "refresh the page", or in this case, the window. You could expect it to be done manually, or you could do it automatically via timer. I don't see why that is overkill. Indeed, just like HTTP has E-Tags or Cache-control headers, you would use some basic checks to verify that the db was modified between retrievals so that you don't have to download the entire thing at each timer cycle. Using $crc/$md5/$sha1 would work fine, as would a timestamp on your db as suggested.
Unless your db is extremely large, I would suggest just downloading the whole thing. Dealing with delta changesets is complicated and *that* would likely be overkill. Expecting my colleagues to refresh the database before making a change isn't going to happen, so it needs to be automatic and fool proof :p I'll have a play around with polling the file for changes and refreshing the db and also my own idea. Thanks for the suggestions everyone
|
|
|
|
Joined: Jan 2004
Posts: 1,361
Hoopy frood
|
Hoopy frood
Joined: Jan 2004
Posts: 1,361 |
The difficulty is that all three terminal server sessions are running the same installation of mirc, so how would each know which port to listen on? You pick a random number from a range, and make sure no other clients are already using it (from the text file).
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
Keep in mind that your colleagues might NOT want the db to refresh automatically because they might be reading old data to keep track of some numbers/text-- having it change automatically on them tends to be confusing unless the data is known to be temporal in nature (stock prices, ping time, etc).
Why not have your server database have row granularity when presenting results? As in, when someone is viewing the whole db, it just shows up normally and doesn't refresh. Then, when a user clicks a row to edit it, you do a lookup on the db for that row and update it before presenting an update dialog. If you only need the rows updated in order for them to make the proper changes, they only need the specific rows that they are changing to be updating, not the whole data set.
You could have a refresh/auto-refresh button too, of course.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
OP
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
That's not a bad idea actually. I'll try doing it that way if my current method doesn't work out very well.
What I'm doing now is simply recording the $file().mtime value in a variable and comparing the variable to the current $file().mtime value at the time of making any changes. If any changes have been made, it refreshes the database and then alerts the user they'll have to repeat the action they just did (as the field they're trying to work with could have already been updated or removed by somebody else).
Cheers
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
You don't even need to refresh the db to tell the user that the db was updated after their commit. You just need to implement an optimistic offline lock. In other words, just version the tables in your database and check that the user's updated data is being made on the latest version of the row when sending the new data. If version=48 and the server has version=49, you send them back to window and tell them to refresh.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
|