A real doozy

I have to find a way to keep our main database in sync with dozens of mobile users with laptops who will only synchronize periodically. Holy crap.

Comments

  • : I have to find a way to keep our main database in sync with dozens of mobile users with laptops who will only synchronize periodically. Holy crap.


    That is an evil project. I remember some contact management software we had here called Goldmine. Very evil. Thats had a sync option.. always f**cked up.

    Anyway... tell them to get VPN's to the office and use Terminal Services as their. No version control of the apps needed. Thats the best way to do it. No problems for you.. only for your Network dudes.

    Have a good weekend Amigo.
  • : : I have to find a way to keep our main database in sync with dozens of mobile users with laptops who will only synchronize periodically. Holy crap.
    :
    :
    : That is an evil project. I remember some contact management software we had here called Goldmine. Very evil. Thats had a sync option.. always f**cked up.
    :
    : Anyway... tell them to get VPN's to the office and use Terminal Services as their. No version control of the apps needed. Thats the best way to do it. No problems for you.. only for your Network dudes.

    Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
  • : Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
    :

    How they are doing it now? Or it's just something new?

  • : : Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
    : :
    :
    : How they are doing it now? Or it's just something new?

    Something new. Right now they use paper forms and fill out information by hand while they interview people, then they return to their local office and enter all the info into a Mainframe terminal. The system we're creating is to replace the mainframe and all paperwork.
  • : : : Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
    : : :
    : :
    : : How they are doing it now? Or it's just something new?
    :
    : Something new. Right now they use paper forms and fill out information by hand while they interview people, then they return to their local office and enter all the info into a Mainframe terminal. The system we're creating is to replace the mainframe and all paperwork.
    :
    How about web? I am working on very similar project but we have just a dozen not dozens users. So we decided to do that through RAS server using phone #. We are trying to keep our users out of Internet (last time one lady brought her laptop fully loaded by virii - 150 of them were there) that's why we choose RAS. Do you users have access to Internet or to phone line?
  • : : : : Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
    : : : :
    : : :
    : : : How they are doing it now? Or it's just something new?
    : :
    : : Something new. Right now they use paper forms and fill out information by hand while they interview people, then they return to their local office and enter all the info into a Mainframe terminal. The system we're creating is to replace the mainframe and all paperwork.
    : :
    : How about web? I am working on very similar project but we have just a dozen not dozens users. So we decided to do that through RAS server using phone #. We are trying to keep our users out of Internet (last time one lady brought her laptop fully loaded by virii - 150 of them were there) that's why we choose RAS. Do you users have access to Internet or to phone line?

    At some point they will connect to the network, either dialup or through some other means (depends on which office they're in), but while they're in the field gathering data, they could be in any godforsaken corner of the state, and will most likely be in the houses of other people who may or may not have electricity, let alone phone lines. We have to assume that they will only have periodic connection for synchronization. We've started joking that it would be easier and cheaper for the agency to just purchase a fleet of vans and offer a taxi service to the offices. Bring the people to us rather than send interviewers to the people. LOL.
  • :while they're in the field gathering data, they could be in any godforsaken corner of the state, and will most likely be in the houses of other people who may or may not have electricity, let alone phone lines.
    :
    I thought I immigrated to America not Africa ;-)
  • : :while they're in the field gathering data, they could be in any godforsaken corner of the state, and will most likely be in the houses of other people who may or may not have electricity, let alone phone lines.
    : :
    : I thought I immigrated to America not Africa ;-)

    I don't think they yet realize how complicated this idea is. It's like they want bleeding-edge distributed technology, but without paying for it.
  • : I don't think they yet realize how complicated this idea is. It's like they want bleeding-edge distributed technology, but without paying for it.
    :
    It's absolutely normal. All users want that :-D.
  • : : : : : Not sure if that's even possible, let alone an option. The budget has effectively zero dollars in it and the "network" is statewide in the fourth (or maybe sixth, I forget) largest state in the US.
    : : : : :
    : : : :
    : : : : How they are doing it now? Or it's just something new?
    : : :
    : : : Something new. Right now they use paper forms and fill out information by hand while they interview people, then they return to their local office and enter all the info into a Mainframe terminal. The system we're creating is to replace the mainframe and all paperwork.
    : : :
    : : How about web? I am working on very similar project but we have just a dozen not dozens users. So we decided to do that through RAS server using phone #. We are trying to keep our users out of Internet (last time one lady brought her laptop fully loaded by virii - 150 of them were there) that's why we choose RAS. Do you users have access to Internet or to phone line?
    :
    : At some point they will connect to the network, either dialup or through some other means (depends on which office they're in), but while they're in the field gathering data, they could be in any godforsaken corner of the state, and will most likely be in the houses of other people who may or may not have electricity, let alone phone lines. We have to assume that they will only have periodic connection for synchronization. We've started joking that it would be easier and cheaper for the agency to just purchase a fleet of vans and offer a taxi service to the offices. Bring the people to us rather than send interviewers to the people. LOL.
    :
    This is similar to what I'm doing. I have a number of remote databases that periodically connect to the internet and transfer any modified records to the main database. Each remote db has a 'linked server' defined (I'm using SQL Server 7).
    Also, I can kill the remote db and have it rebuild from the main db.
  • : This is similar to what I'm doing. I have a number of remote databases that periodically connect to the internet and transfer any modified records to the main database. Each remote db has a 'linked server' defined (I'm using SQL Server 7).
    : Also, I can kill the remote db and have it rebuild from the main db.

    That sounds a lot like what we need to do. Do you have any advice?
  • : : This is similar to what I'm doing. I have a number of remote databases that periodically connect to the internet and transfer any modified records to the main database. Each remote db has a 'linked server' defined (I'm using SQL Server 7).
    : : Also, I can kill the remote db and have it rebuild from the main db.
    :
    : That sounds a lot like what we need to do. Do you have any advice?
    :

    The biggest problem is knowing whether to insert or update a record. Using Linked servers doesn't use indexes so querying across the net to find out if the record exists is time consuming. So I created Transfer_ tables which match the final destination tables, and always insert into them, then run a procedure locally to insert or update into the final destination.
    I had the luxury of adding a column to every table to indicate if the record was modified. Another way is to have a table with "Table" and "Key" if you see what I mean.
    Another problem is Identity (Autocounters) on the remote db's. Again I had the luxury to assign a unique ID to each remote db (called Range_ID) and then the main db has a composite key of Range_ID and the Identity field (which is just a normal int on the main db)
    That's the gist of it. Hope it helps.
  • [b][red]This message was edited by lionb at 2002-11-11 11:14:17[/red][/b][hr]
    :
    : The biggest problem is knowing whether to insert or update a record. Using Linked servers doesn't use indexes so querying across the net to find out if the record exists is time consuming. So I created Transfer_ tables which match the final destination tables, and always insert into them, then run a procedure locally to insert or update into the final destination.
    : I had the luxury of adding a column to every table to indicate if the record was modified. Another way is to have a table with "Table" and "Key" if you see what I mean.
    : Another problem is Identity (Autocounters) on the remote db's. Again I had the luxury to assign a unique ID to each remote db (called Range_ID) and then the main db has a composite key of Range_ID and the Identity field (which is just a normal int on the main db)
    : That's the gist of it. Hope it helps.
    :
    I was talking about my project with my wife (usually we discussed out projects quite rarely but it happens yesterday) and realized that she and her group just finished project very similar to yours. Looks like your state and ours work on the same program ;-). She told me that they use Access and SQL Server for that project. Access is installed on users laptop (they choose that way because it chipper and no problem with licensing ). When users are collecting information they use Access. At the end of the day or some other times (there is no schedule), the collectors come to their offices and upload all information from Access to local SQL server database (they also have possibility to do that through dual up connection). If uploading is OK program delete all records from Access database on user laptop. At the end of the day, they run VB program installed in office machine to upload all information from local databases to the main database. They avoid problem with inserting/updating record using SSN as criteria.
  • : The biggest problem is knowing whether to insert or update a record. Using Linked servers doesn't use indexes so querying across the net to find out if the record exists is time consuming. So I created Transfer_ tables which match the final destination tables, and always insert into them, then run a procedure locally to insert or update into the final destination.

    Cool.

    : I had the luxury of adding a column to every table to indicate if the record was modified. Another way is to have a table with "Table" and "Key" if you see what I mean.

    We do have a "last_modified_date" timestamp field on every table.

    : Another problem is Identity (Autocounters) on the remote db's. Again I had the luxury to assign a unique ID to each remote db (called Range_ID) and then the main db has a composite key of Range_ID and the Identity field (which is just a normal int on the main db)

    We solved this problem by using GUIDs for identity fields. We were using integers incremented by sequences (Oracle's hack for autoincrement), but once we realized how hard it would be to avoid key conflicts, we switched to 32-byte GUID fields.

    : That's the gist of it. Hope it helps.

    Thanks
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories