 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
karen
Guest
|
 Posted: Mon May 16, 2005 5:15 pm Post subject: Briefcase Model/Multi tier |
 |
|
I have a Delphi 2005 application with a interbase database(v5).
I have some questions on how the Briefcase model handles changes and refreshes the client.
1) I understand that the .apply will reconcile with the server any changes on the client but how do you handle one client stepping on another. In other words the clients can make changes offline (so I can't do record locking) when they get online they could overlay a previous update done my another client just because they happen to be the last one to connect.
scenario
client 1 changes phone number for customer A offline on 5/1/05
client 2 changes phone number for customer A offline on 5/3/05
client 2 gets online and the phone number (5/3) is updated on server
client 1 gets online after client two and the phone number (5/1) is updated on server
What techniques have other devoplers used to avoid this from happening.
2) How does the client get a fresh copy of the server database. If a client connects and a .refresh is issued does it only send down updates to the clients. If not, does it send the entire database. We are concerned with performance. When our clients connect how long will it take to give them a fresh copy of the server data. Let's say there are about 1000 name address records in a table and maybe a could other supporting tables
In short, I think we have a perfect application to take advantage of the briefcase model. We have a name/address database that District Managers travel around with laptops and update/view as needed. The changes are at a minimum but it is very important the they have quick access to this information and make changes offline as needed and sync up the next time they connect.
3) What are the experiences others have had with a briefcase model
|
|
| Back to top |
|
 |
Kostas Terzides
Guest
|
| Posted: Tue May 17, 2005 2:53 pm Post subject: Re: Briefcase Model/Multi tier |
|
|
You should tell us if you are using a .NET application (ADO .NET), ADO,
or Datasnap (that is Datasetprovider/clientdataset) or any other data
access technology. In case you use Datasnap, then you might find the
following useful:
| Quote: | I have a Delphi 2005 application with a interbase database(v5).
I have some questions on how the Briefcase model handles changes and refreshes the client.
1) I understand that the .apply will reconcile with the server any changes on the client but how do you handle one client stepping on another. In other words the clients can make changes offline (so I can't do record locking) when they get online they could overlay a previous update done my another client just because they happen to be the last one to connect.
scenario
client 1 changes phone number for customer A offline on 5/1/05
client 2 changes phone number for customer A offline on 5/3/05
client 2 gets online and the phone number (5/3) is updated on server
client 1 gets online after client two and the phone number (5/1) is updated on server
|
Set provider.UpdateMode to a restrictive option (upWhereChanged,
upWhereAll). This way the WHERE portion of the UPDATE or DELETE SQL
clause that Datasnap automatically creates during ApplyUpdates will
include either the fields that were changed by the user or all the
fields. In that case the statement will fail (if another user has
already changed some of the fields) because the relevant record will not
be found. DataSnap then raises an exception that is returned to client
side and you can handle this setting a handler for cds.OnReconcileError
(You can use the Delphi help example and use the standard Reconciliation
Error Dialog).
Another technique (not only related to Datasnap) is to use TimeStamp
fields. Add a time stamp field in the table, and set a trigger in the
database so that it takes the current date/time (now function) each time
a record is changed. Set the pfInKey provider flag for this field in
DataSetProvider.Dataset and just set Provider.UpdateMode to
upWhereKeyOnly. This is the most restrictive option, but it also is the
fastest (because the WHERE portion of the clause will contain the
minimum number of fields) and AFAIK the only way to handle concurrency
conflicts in case of BLOB/Memo fields.
Depending on buisness logic you might want to be even more restrictive,
that is check the number of records in the database and if it isn't the
same as the client "knows" (in case someone else inserted a new record)
raise an exception. OTOH upWhereChanged gives you the flexibility to
Merge changes if different fields are changed by two distinct users
(again that depends on buisness logic) and upWhereKeyOnly (without using
a time stamp field, but just the primary key fields) is the less
restrictive option.
| Quote: | 2) How does the client get a fresh copy of the server database. If a client connects and a .refresh is issued does it only send down updates to the clients. If not, does it send the entire database. We are concerned with performance. When our clients connect how long will it take to give them a fresh copy of the server data. Let's say there are about 1000 name address records in a table and maybe a could other supporting tables
In short, I think we have a perfect application to take advantage of the briefcase model. We have a name/address database that District Managers travel around with laptops and update/view as needed. The changes are at a minimum but it is very important the they have quick access to this information and make changes offline as needed and sync up the next time they connect.
|
Cds.Refresh refetches all the records from server (at least as many as
PacketRecords defines) and not only those that are changed and that
means that it has to be used with care. You can use Cds.RefreshRecord
(from client side) to refresh the data of a single record, but you are
not able to know up front if this record is changed (in server). You
could implement a call back function in server (see
http://bdn.borland.com/article/0,1410,29539,00.html)
to notify clients of what records have been changed and then only
refresh these records, but this is not possible if a SOAP connection is
used (or any connection using HTTP AFAIK).
Another option is to use Cds.RefreshRecord prior to letting a user
changing a particular record and thus avoid concurrency conflicts, but
this method drives us away from briefcase model.
Probably, there are other techniques of reducing network traffic that I
am not aware of and may be other (newer) database access technologies
(such as ADO .NET) provide more options, but I don't have any experience
with these.
|
|
| Back to top |
|
|
karen
Guest
|
| Posted: Wed May 18, 2005 8:33 pm Post subject: Re: Briefcase Model/Multi tier |
|
|
Thanks for you comments.
I will probably use ADO but at this point I am defining the best architecture. You peek my interest with Datasnap, is that the best approach?
We are using Delph 2005 with Interbase v5.5 (.Net is an option).
I will welcome any recommendations.
In reference to your comments about timestamp, Is that at the field level or the record level?
......karen
Kostas Terzides <kterz (AT) otenet (DOT) gr> wrote:
| Quote: | You should tell us if you are using a .NET application (ADO .NET), ADO,
or Datasnap (that is Datasetprovider/clientdataset) or any other data
access technology. In case you use Datasnap, then you might find the
following useful:
I have a Delphi 2005 application with a interbase database(v5).
I have some questions on how the Briefcase model handles changes and refreshes the client.
1) I understand that the .apply will reconcile with the server any changes on the client but how do you handle one client stepping on another. In other words the clients can make changes offline (so I can't do record locking) when they get online they could overlay a previous update done my another client just because they happen to be the last one to connect.
scenario
client 1 changes phone number for customer A offline on 5/1/05
client 2 changes phone number for customer A offline on 5/3/05
client 2 gets online and the phone number (5/3) is updated on server
client 1 gets online after client two and the phone number (5/1) is updated on server
Set provider.UpdateMode to a restrictive option (upWhereChanged,
upWhereAll). This way the WHERE portion of the UPDATE or DELETE SQL
clause that Datasnap automatically creates during ApplyUpdates will
include either the fields that were changed by the user or all the
fields. In that case the statement will fail (if another user has
already changed some of the fields) because the relevant record will not
be found. DataSnap then raises an exception that is returned to client
side and you can handle this setting a handler for cds.OnReconcileError
(You can use the Delphi help example and use the standard Reconciliation
Error Dialog).
Another technique (not only related to Datasnap) is to use TimeStamp
fields. Add a time stamp field in the table, and set a trigger in the
database so that it takes the current date/time (now function) each time
a record is changed. Set the pfInKey provider flag for this field in
DataSetProvider.Dataset and just set Provider.UpdateMode to
upWhereKeyOnly. This is the most restrictive option, but it also is the
fastest (because the WHERE portion of the clause will contain the
minimum number of fields) and AFAIK the only way to handle concurrency
conflicts in case of BLOB/Memo fields.
Depending on buisness logic you might want to be even more restrictive,
that is check the number of records in the database and if it isn't the
same as the client "knows" (in case someone else inserted a new record)
raise an exception. OTOH upWhereChanged gives you the flexibility to
Merge changes if different fields are changed by two distinct users
(again that depends on buisness logic) and upWhereKeyOnly (without using
a time stamp field, but just the primary key fields) is the less
restrictive option.
2) How does the client get a fresh copy of the server database. If a client connects and a .refresh is issued does it only send down updates to the clients. If not, does it send the entire database. We are concerned with performance. When our clients connect how long will it take to give them a fresh copy of the server data. Let's say there are about 1000 name address records in a table and maybe a could other supporting tables
In short, I think we have a perfect application to take advantage of the briefcase model. We have a name/address database that District Managers travel around with laptops and update/view as needed. The changes are at a minimum but it is very important the they have quick access to this information and make changes offline as needed and sync up the next time they connect.
Cds.Refresh refetches all the records from server (at least as many as
PacketRecords defines) and not only those that are changed and that
means that it has to be used with care. You can use Cds.RefreshRecord
(from client side) to refresh the data of a single record, but you are
not able to know up front if this record is changed (in server). You
could implement a call back function in server (see
http://bdn.borland.com/article/0,1410,29539,00.html)
to notify clients of what records have been changed and then only
refresh these records, but this is not possible if a SOAP connection is
used (or any connection using HTTP AFAIK).
Another option is to use Cds.RefreshRecord prior to letting a user
changing a particular record and thus avoid concurrency conflicts, but
this method drives us away from briefcase model.
Probably, there are other techniques of reducing network traffic that I
am not aware of and may be other (newer) database access technologies
(such as ADO .NET) provide more options, but I don't have any experience
with these.
|
|
|
| Back to top |
|
|
Kostas Terzides
Guest
|
| Posted: Wed May 18, 2005 9:12 pm Post subject: Re: Briefcase Model/Multi tier |
|
|
karen wrote:
| Quote: | Thanks for you comments.
I will probably use ADO but at this point I am defining the best architecture. You peek my interest with Datasnap, is that the best approach?
We are using Delph 2005 with Interbase v5.5 (.Net is an option).
I will welcome any recommendations.
|
If you choose to build a .NET app then the following might seem useful:
http://bdn.borland.com/borcon2004/article/paper/0,1963,32164,00.html
If you stick to Win32 application, then I'd recommend IbExpress/Datasnap
or DbExpress/Datasnap instead of ADO (this is purely subjective though)
because I think it gives you more control on how thinks work (ADO does
some things "automagically"- this could be considered either as an
advantage or a disadvantage).
In addition, I'd highly recommend upgrading from v5.5 of Interbase (new
versions have a lot of new features). You could always choose Firebird
which is the open source alternative.
| Quote: |
In reference to your comments about timestamp, Is that at the field level or the record level?
.....karen
It is at the record level (an extra field in the table). |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
