on 2013 Jun 06 2:21 PM
ok guys,
I have to prepare for a session to a meeting where I have to convince developers to switch from Visual Studio to Powerbuider.
Can you give me 10 good reasons for the mission?
ty
GMY
Help others by sharing your knowledge.
AnswerRequest clarification before answering.
8. The DataWindow performs better on retrievals because it retrieves rows in blocks rather than one at a time (assuming you don't have code in the RetrieveRow event).
9. PowerScript is a very clear, no-surprises language. Readable code means fewer bugs and easier maintenance. And the learning curve is very rapid.
10. PB is object-oriented. Pick one of the available frameworks, spend a little time customizing it, and each time you add a feature you will find 50% of the work is done by inheriting the appropriate object. And it's the boring part of the work, the wiring and plumbing, leaving you to concentrate on the business logic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jerry;
FYI ... #8 is not true ... while the DB driver get an entire packet, the DWO runs an internal FETCH loop 1 row at a time to get all the rows for the primary buffer. Things can also go better or worse on top of that depending on whether the developer used an ODBC connection, OLE-DB, ADO.Net, JDBC, native, etc driver connection mechanism.
Regards ... Chris
Really? Then what would be the point of the Block DBMS parameter?
Block (ODBC, OLE DB, Oracle, and SNC)
Description
For those interfaces that support it, Block specifies the cursor blocking factor when connecting to a database. The blocking factor determines the number of rows that a DataWindow object can fetch from the database at one time.
Using the Block parameter can improve performance when accessing a database in PowerBuilder.
"internal" = memory to memory = very very fast, mircoseconds. Blocking reduces the number of times the client must handshake with the server over the network. As I recall it's two or three messages each before and after each data block - regardless of the actual number of rows in that block. Time for each would be in milliseconds. As always, it depends on the speed of the network , traffic level, and load on the server, but with a substantial result set the difference is often discernible to carbon-based life forms.
Hi Bruce;
That is an excellent question and probably a big misconception in PB/DB-Land!
You have to remember that the real DB client driver is the one that is handling the DB data packetization on both sides of the C/S fence. PB's DB driver is not the one doing that .. in fact, the PB DB driver ( for example PBSNC125.dll) is really only an "interface" to the real DB client driver that the DBMS vendor or 3rd party provided.
So... many things that you put in the SQLCA.DBParm or other SQLCA settings are really just "passed through" to the real DB driver from PB's "interface" driver. Thus, when the blocking eature you refer to is activated its actually implemented at the real DB driver level - then, the PB interface DB driver runs a FETCH on that buffer to get it into the PB application.
FYI: Just run a PB SQL Trace and a DB Driver SQL trace and you will see what I mean.
HTH
Regards ... Chris
| User | Count |
|---|---|
| 9 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.