Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Vfp 8.0 cursoradapter versus powerbuilder
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00777592
Message ID:
00778191
Vues:
23
>>For years in powerbuilder we could connect to any dbms via odbc, we could use a builder (like the one we now have in vfp 8.0) to run a sql statement against a remote table, then we could change the data on the client and send the updates to the server. All these can be done now in VFP - even with some limitations like the 256 char limit. The differense is that with powerbuilder no matter if the backend is SQL server or oracle or anything, Powerbuilder can handle update conflicts. How can Powerbuilder do that in contrast with vfp 8.0, where to solve the update conflict problem we have to program differently for every specific backend (either changing the update statement or via stored procedures e.t.c.) Is this a vfp cursoradapter limitation or a backend or odbc limitation ?
>>
>>Thanks for any reply
>
>Dimitris,
>
>To start, I must admit that my experience with Powerbuilder is limited to version 6.5.
>
>Yes, this is a difference between to two problems. OTOH, PB makes it easier to handle certain common tasks, like update conflicts better than VFP. However, IMV, working with PB requires, overall, more work and does confine the developer more than VFP does.
>
>It seems to me that while PB does makes certain tasks easiers, VFP gives you a greater amount of flexibility (not to mention a vastly superior IDE). My experience is that VFP apps are easier to develop and maintain.
>
>To address the CursorAdapter part of your post, I'd say that this particular functionality's strength is in abstracting the back end. Certainly, a good sub-classing of this class to handle the issues you mention not only addresses this problem, but allows a much more flexible approach overall.
>
>Regards,


Thank you for the response

my main question was how powerbuilder could manage the abstarction regarding the update conflicts (you dont bother for the backend) and for cursoradaptor we have to handle it differently depending on the back end. Or to put it differently, can the cursor adapter be programmed so that it can handle conflicts no matter which the back end is and of course without bothering making stored procedures??

Best Regards

Dimitris
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform