Vote for PocketBuilder!

Please take a few minutes and vote for PocketBuilder in the 2005 Mobile Star Awards(TM), and then pass this on to customers and partners! PocketBuilder is a candidate in the Enterprise Software: Developer Tool category.

The Mobile Star Awards hire no judges, and are meant to be open to all. Winners are chosen only by email subscribers of MobileVillage's free twice-monthly mobile/wireless technology newsletter, Go Mobile(R).

If you already receive Go Mobile by email, you can vote right away. If you are not a subscriber, you can sign up at http://www.mobilevillage.com/subscribe-gomobile.htm. Subscribing is free, quick, and immediate.

Once you are subscribed, you can vote online at: http://www.mobilevillage.com/awards.htm.

Voting runs until Sept. 30, 2005, and winners will be announced in early October.

There are several important voting rules, listed on the voting page:

• You must enter your email address at the bottom of the voting page, to validate that you are a Go Mobile subscriber.


• After voting, you must remain subscribed to Go Mobile for at least five more months (about 10 issues.)


• Please don't vote in categories where you have no experience. Do vote in categories in which you have experience, or enough interest to read the entrants' profiles.


• To help ensure fairness for all entrants, MobileVillage will not accept votes: 1) twice from the same person; 2) on behalf of another person; 3) exceeding 40 votes by employees of an entering company; and 4) from entrants' family members, pets, etc. However, MobileVillage welcomes all votes by entrants' customers and qualified business partners.

DataWindow.Net 2.0 Sneak Preview

We are a little over a month away from the Beta for DataWindow .NET 2.0 and here is your chance to get a sneak preview of what that release has to offer.

A sneak preview webcast will be held on Thursday September 29th at 10 am PDT/ 1 pm EDT.

Attendence is free, but space is limited and you must register at:

http://www.customermining.com/Sybase/webinar3.html

Here are some of the features you can expect to learn more about at this webcast:

- Visual Studio 2005 Support
- Dot Notation (Indexer) access to DataWindow Data
- Hierarchical (Treeview) Style DataWindow
- Enhanced Drop Down DataWindows for Web Apps
- Using .NET Datasets and Datatables as DataWindow datasources

Well, maybe you can teach an old dog new tricks…

I was using the GenerateGUID function in PowerScript the other day (and it's been quite a while since I last used it). I thought the example given in the online help was in error, because it showed the REF keyword being used in the actual use of the function.

Turns out the example is correct. In fact, as the PowerBuilder documentation indicates, the REF keyword is required in the actual call when working with an OLE Server application that attempts to return values in arguments. The following is a copy of the relevent section of the HTML books. How odd to consider how long I've been working with PB and OLE that I just noticed this.

Or perhaps its a symptom of something else. They say one of the best things about getting older is you get to meet all these nice new friendly people over and over again...

==============================================================================

Passing arguments by reference

If an OLE server expects an argument to be passed by reference so that it can pass a value back to your script, include the keyword REF just before the argument. This is similar to the use of REF in an external function declaration:

olecontrol.Object.functionname ( REF argname )

In these generic examples, the server can change the values of ls_string and li_return because they are passed by reference:

string ls_string
integer li_return
ole_1.Object.testfunc(REF ls_string, REF li_return)

This example illustrates the same function call using an OLEObject variable.

OLEObject ole_obj
ole_obj = CREATE OLEObject
ole_obj.ConnectToNewObject("servername")
ole_obj.testfunc(REF ls_string, REF li_return)

Brute force pbtrace.log file processing

Every had to search through a large PBTRACE.LOG file to find the problematic SQL statement that is causing your application to run slow? If you've moved to PowerBuilder 10.2 it's less of an issue because of the enhancements to database tracing they've added to that version. However, if you're still using anything earlier, it can be a pain to find the statement in a large log file.

So here's a brute force method of handling it. Import the pbtrace.log file into Excel, and then insert three columns before the data. In the first column, add the following formula in the first cell and then copy it for each row of data:

=IF(ISERROR(SEARCH("MilliSeconds",D1)),0,SEARCH("MilliSeconds",D1))

That forumla determines if there is timing data for the particular row in the pbtrace.log file.

In the second column, add the following forumla in the first cell of the second column and then copy it for each row of data:

=IF(A1>0,SEARCH("(",D1,A1-9),0)

That forumla determines where the beginning of the numeric value for the timing information begins.

Finally, add the following formula in the first cell of the third column and then copy it for each row of data:

=IF(A1>0,VALUE(MID(D1,B1+1,A1-B1-2)),0)

That forumula strips out the numeric value from the timing data.

You should now be able to perform a descending sort on the third column to determine which SQL statements are the problematic ones.