 |
|||||||||
|
|||||||||
|
|
I just stumbled on the Bill Gates & Jerry Seinfeld commercial (at "Shoe Circus" of all places!) and it's a real hoot.
http://www.youtube.com/watch?v=afR5J7eskno
It looks like some others will be coming out too.
My 9-year old daughter finally got approval from mom to use a nailgun. Not the big framing gun but a brad gun to fire 3/4 inch nails for the garage doors I'm making (a separate story - historic district - historic house - cedar garage doors...). She was nice a careful, no Three Stooges here. But she DID like the power and sense of accomplishment (like when she was 'certified' on the drill...)
I'll be posting a picture in a couple of days.
In the PowerBuilder 11.0 timeframe, Sybase went to a new licensing scheme called "SySAM". This is based on the FLEXnet license manager by Macrovision. This is the same technology used by ASE, PowerDesigner, and other Sybase products (but not iAnywhere's SQL Anywhere...).
Basically, this uses a license file (PB_SySAM.LIC), a properties file (pb110_sysam.properties), and the magic sauce provided by the FLEXnet folks. Everything has to be properly hooked up for the PowerBuilder IDE to properly initialize, so some background and debugging tips might help for the times things DON'T work...
The PowerBuilder Help -> About dialog box provides information about your current license state. This displays whether you are currently fully licensed or whether you are running in a Trial or Grace mode. If you should be fully licensed, but the About box states you are still in Trial or even Grace, this should be looked into immediatly because these are timed and will soon expire. Leaving you with an IDE that refuses to start.
Most of the issues are because the directory being looked into is not what people expect. With Windows XP and Vista, the directory of "personalized" settings is no longer in the classic 'PowerBuilder' directory, but in a user specific location.
For Windows XP this is usually something like:
c:\documents and settings\...user...\local settings\application data\sybase\powerbuilder 11.0
For Vista this is something like:
c:\users\...user...\AppData\Local\Sybase\PowerBuilder 11.0
This directory setting can be viewed and changed in the PowerBuilder IDE in the Tools -> System Options -> Initialization Path setting. This is stored in the registry in the "InitPath" setting.
This personalized directory is the focus of attention for all SySAM activity. This contains the copies of PB.INI, *.LIC, and the properties file that are actually being used. The copies in the original \Program Files\Sybase\... directory are pristine copies from the installation process and are not used.
C.1) PB.INI
The good-old ini file with all the handy settings we are all familiar with. To assist debugging SySAM issues we have introduced a couple new properties.
C.1.1) LogSySAM
Logging is the easiest way to see what is the true nature of the SySAM complaint. This also ensures that you are dealing with the correct location for the license files.
[pb]
LogSySAM = 0 | 1 | 2
(default to zero)
0 := none
1 := normal logging level
2 := yet more logging
Logging creates the file pb110_sysam.log in the same directory. This is typically the first thing that the customer service folks will ask you to do. A quick glance at this file will solve 90% of the SySAM problems.
C.1.2) SySAMTrace
The SySAM trace provides more details about the internals of what SySAM is looking for. I have found this useful when dealing with served licenses.
[pb]
LogSySAM = 1
SySAMTRACE= 0xfffe
This adds a LOT of details (and noise) to the same log file.
C.2) pb110_sysam.properties
The properties file is partially encrypted and partially clear text. This provides information to the licensing system about the type of license to expect and whether the license file is local or from a server. You might be tempted to think that simply changing the "InstalledEdition" to Enterprise that you would be magically elevated. However, this value is used to request the edition license. The request could be refused if the true license is not really an Enterprise license.
C.3) *.LIC - Local File
The true license file, or a reference to the license server. You may have multiple license files (common with ASE and servers, not very common with a tool like PB or PD). These license files are each examined during the startup of the IDE and the first one that satisfies the license request is used. This can sometimes be confusing when you have a beta license or some other condition and things start acting odd.
When you have multiple versions of PowerBuilder installed, things can get confused. An easy way to "eyeball check" the license file, is the version field. This is in the license file on the same line as INCREMENT ...
PowerBuilder and InfoMaker 11.0, 11.1, and 11.2:
INCREMENT PB_xxxx SYBASE 2007.0212
PowerBuilder and InfoMaker 11.5:
INCREMENT PB_xxxx SYBASE 2008.0624
(BTW - since *I* picked the numbers, these are dates important to ME - anniv of first date and wedding anniv. I don't know what I will pick for PowerBuilder 12.0 and PocketBuilder 3.0 but it will be some value that I like...)
C.4) *.LIC - Server Reference
This is a simple reference to the license server. It has no real details because the license server has the true licenses. The licenses fed into the server are similar to the ones above, but the client machine has only a simple "look over there" type of information. A classic server reference is like:
# Generated by PowerBuilder at 2008-Jul-24 11:16:39
# Standalone Seat - Served
SERVER bar.tarfu.com ANY 27000
VENDOR SYBASE
USE_SERVER
There are two common problems I see on the newsgroups, and my typical approach to solve them.
D.1) License failure on IDE startup
This failure is when the IDE displays the license wizard and otherwise refuses to start up. This is typically because the true license from Sybase eShop was never applied or the initialization directory was moved without the license files being (manually!) moved. Knowing the directory details (above) and how to further investigate with the logging should help solve the vast majority of these problems.
D.2) System clock setback detected
This is happens because SySAM also looks around in Windows to make sure the customer has not diddled their system clock to gain extra days (or years!) on a 30 day trial license. However, this can be spurious because of other system tests and even bad applications.
The only solution I've found for this (well, other than formatting the C: drive and reinstalling the OS) is to use an advanced search for all files with a create/modify/access date LATER than today and either 'touch' or simply delete those files.
Of course - if you run PowerBuilder with a future date, then set the clock back, that is detected and you may be permanently locked out.
Note:
For PowerBuilder 11.5 (and probably even 12), the basic technology is the same, but the filenames and directory locations have the expected changes.
This territory has been covered many times for the last dozen years, but I just spent some time to figure out the right API to use, so this may save you (or anybody else) that precious time when you have the same need.
We all know and appreciate that both PowerBuilder and PocketBuilder (and C# and Java) are "managed environments", in other words, the memory and lifetime of objects is all managed for you in a protected universe. However, like C# and Java, you SOMETIMES need to get access to raw memory sitting somewhere out in the computer. The typical case is when you need to handle a message or deal with a DLL API which is not already mapped and handled by the PowerBuilder/PocketBuilder runtime engine.
My current need was driven by a customer request (through professional services in Europe) to be notified when the user clicks the "next month" arrow button on a drop-down calendar control. I knew this came through as a WM_NOTIFY, with the additional values tacked onto the end of the NMHDR structure. Unfortunately, for a multitude of reasons, PowerBuilder (and PocketBuilder) do not have any helper functions when dealing with the WM_NOTIFY message.
The core of dealing with the WM_NOTIFY is to make a local (managed) copy of the memory block that is passed to the message handler simply as a pointer (in the LParam).
This blog item is about copying that memory block from the Windows memory space into a managed structure in the PowerBuilder (or PocketBuilder) application.
First - let's define some local structures (this is all in a UO...)
type str_notify_header from structure
unsignedlong hwnd_from
unsignedlong idFrom
unsignedlong code
end type
Create the functions which would copy the data
// *** Copy the NotifyMessage header locally ***
FUNCTION ulong CopyNMHeader_WIN( REF str_notify_header nmHeader, &
ulong lSourceAddress, ulong cBytes ) &
library "kernel32.dll" alias for "RtlMoveMemory"
FUNCTION ulong CopyNMHeader_CE( REF str_notify_header nmHeader, &
ulong lSourceAddress, ulong cBytes ) &
library "Coredll.dll" alias for "memmove"
To actually use this within the WM_NOTIFY handler. Remembering that PowerBuilder and PocketBuilder do not have customer accessible event handlers for WM_NOTIFY, we have to wedge this into the infamous "OTHER" event.
private constant integer WM_NOTIFY = 78 // 0x004e
private constant integer cb_str_notify_header = 12
event other;
// all window messages flow through this event
long nmCode
str_notify_header nmHeader
IF message.number = WM_NOTIFY THEN
Beep( 1 )
f_log( "WM_Notify: wParam=" + STRING(wParam,"hex8") + &
", lparam=" + STRING(lParam,"hex8") )
IF i_isWinCE THEN
CopyNMHeader_CE( REF nmHeader, lParam, cb_str_notify_header )
ELSE
CopyNMHeader_WIN( REF nmHeader, lParam, cb_str_notify_header )
END IF
// Handle based on the Notify Code
nmCode = nmHeader.Code
f_log( ".. NM.Code=" + STRING(nmCode) )
CHOOSE CASE nmCode
CASE MCN_SELCHANGE, MCN_SELECT
... etc ...
As you can see, the "nmHeader" structure contains the contents that were copied in from the location pointed to by the "lParam" passed in by the Windows call.
PowerBuilder also has the ability to properly "marshall" the data from nested structures, however PocketBuilder seems to be trapped a bit by the different memory alignment considerations on the ARM and the X86 CPUs.
Looking into the contents of PowerBuilder types is an area that is not well explored by most people (well, except for maybe Terry, Mr. PBL Peeper). A new person in the PB technical documentation group asked me a question that required some exploring, so I am sharing...
The question was basically - "At RUNTIME - how can I see the values of an enumeration"....
This requires the use of the EnumerationDefinition and EnumerationItemDefinition types built into PowerBuilder.
A simple example to see the values in the built-in enumeration "Alignment"...
First - on a command button...
EnumerationDefinition ed
ed = FindtypeDefinition( "Alignment" )
f_log( ed )
And the specific "f_log" which dives into the type...
public subroutine f_log (EnumerationDefinition a_ed);
// log the contents of the enumeration definition
integer idx
EnumerationItemDefinition eid
// type Definition
f_log( "**** Enumeration Definition ****")
f_log( "Name: " + a_ed.Name )
f_log( "DataTypeOf: " + a_ed.DataTypeOf )
f_log( "isSystemType: " + string(a_ed.isSystemType) )
f_log( "LibraryName: " + a_ed.LibraryName )
// the contained variables
for idx=1 to UpperBound(a_ed.Enumeration)
// each item of the enumeration
eid = a_ed.Enumeration[ idx ]
f_log( "Enum Item[" + string(idx) + "]" )
f_log( " Name: " + eid.Name )
f_log( " Value: " + string(eid.Value) )
next
end subroutine
This results in the following output (the "f_log(string)" results)....
**** Enumeration Definition ****
Name: alignment
DataTypeOf: alignment
isSystemType: true
LibraryName: pbvm115.dll
Enum Item[1]
Name: right
Value: 2
Enum Item[2]
Name: left
Value: 0
Enum Item[3]
Name: justify
Value: 3
Enum Item[4]
Name: center
Value: 1
The IDE and Runtime Update for PocketBuilder, version 2.5.1 (build 1155) is now available from
http://downloads.sybase.com
This EBF is for both the IDE and device side of the product.
The updates include:
In the PocketBuilder tradition, this is a "rollup" of all previous along with new bug fixes and features.
One thing to note - this is just a ZIP file - simply unzip it.
No "setup.exe" or other installers to mess with...
Note:
This was published the day BEFORE Friday the 13th.
Just saw a press release - Sybase and Sun have set a "Guinness World Record" for the worlds largest data warehouse.
"One Petabyte of mixed relational and unstructured data—more than 34 times larger than the largest industry standard benchmark and twice the size of the largest commercial data warehouse known to date ... In total, the data warehouse contains six trillion rows of transactional data and more than 185 million content-searchable documents, such as emails, reports, spreadsheets and other multimedia objects."
mmmmmmm - Petabyte - a thousand terabytes - a million gigabytes....
Ages ago, my wife worked on an early terabyte sized database for a bank in Florida (all managed in PowerBuilder of course - yes - PowerBuilder geekness is "in the family").
PocketBuilder 2.5.1 is getting some new samples from our evangelist Ian Thain (with the documentation written by yours truly). We have added:
Looking into the contents of PowerBuilder types is an area that is not well explored by most people (well, except for maybe Terry, Mr. PBL Peeper). A new person in the PB technical documentation group asked me a question that required some exploring, so I am sharing...
The question was basically - "At RUNTIME - how can I see the values of an enumeration"....
This requires the use of the EnumerationDefinition and EnumerationItemDefinition types built into PowerBuilder.
A simple example to see the values in the built-in enumeration "Alignment"...
First - on a command button...
EnumerationDefinition ed
ed = FindtypeDefinition( "Alignment" )
f_log( ed )
And the specific "f_log" which dives into the type...
public subroutine f_log (EnumerationDefinition a_ed);
// log the contents of the enumeration definition
integer idx
EnumerationItemDefinition eid
// type Definition
f_log( "**** Enumeration Definition ****")
f_log( "Name: " + a_ed.Name )
f_log( "DataTypeOf: " + a_ed.DataTypeOf )
f_log( "isSystemType: " + string(a_ed.isSystemType) )
f_log( "LibraryName: " + a_ed.LibraryName )
// the contained variables
for idx=1 to UpperBound(a_ed.Enumeration)
// each item of the enumeration
eid = a_ed.Enumeration[ idx ]
f_log( "Enum Item[" + string(idx) + "]" )
f_log( " Name: " + eid.Name )
f_log( " Value: " + string(eid.Value) )
next
end subroutine
This results in the following output (the "f_log(string)" results)....
**** Enumeration Definition ****
Name: alignment
DataTypeOf: alignment
isSystemType: true
LibraryName: pbvm115.dll
Enum Item[1]
Name: right
Value: 2
Enum Item[2]
Name: left
Value: 0
Enum Item[3]
Name: justify
Value: 3
Enum Item[4]
Name: center
Value: 1
I just stumbled on the Bill Gates & Jerry Seinfeld commercial (at "Shoe Circus" of all places!) and it's a real hoot.
http://www.youtube.com/watch?v=afR5J7eskno
It looks like some others will be coming out too.
My 9-year old daughter finally got approval from mom to use a nailgun. Not the big framing gun but a brad gun to fire 3/4 inch nails for the garage doors I'm making (a separate story - historic district - historic house - cedar garage doors...). She was nice a careful, no Three Stooges here. But she DID like the power and sense of accomplishment (like when she was 'certified' on the drill...)
I'll be posting a picture in a couple of days.
In the PowerBuilder 11.0 timeframe, Sybase went to a new licensing scheme called "SySAM". This is based on the FLEXnet license manager by Macrovision. This is the same technology used by ASE, PowerDesigner, and other Sybase products (but not iAnywhere's SQL Anywhere...).
Basically, this uses a license file (PB_SySAM.LIC), a properties file (pb110_sysam.properties), and the magic sauce provided by the FLEXnet folks. Everything has to be properly hooked up for the PowerBuilder IDE to properly initialize, so some background and debugging tips might help for the times things DON'T work...
The PowerBuilder Help -> About dialog box provides information about your current license state. This displays whether you are currently fully licensed or whether you are running in a Trial or Grace mode. If you should be fully licensed, but the About box states you are still in Trial or even Grace, this should be looked into immediatly because these are timed and will soon expire. Leaving you with an IDE that refuses to start.
Most of the issues are because the directory being looked into is not what people expect. With Windows XP and Vista, the directory of "personalized" settings is no longer in the classic 'PowerBuilder' directory, but in a user specific location.
For Windows XP this is usually something like:
c:\documents and settings\...user...\local settings\application data\sybase\powerbuilder 11.0
For Vista this is something like:
c:\users\...user...\AppData\Local\Sybase\PowerBuilder 11.0
This directory setting can be viewed and changed in the PowerBuilder IDE in the Tools -> System Options -> Initialization Path setting. This is stored in the registry in the "InitPath" setting.
This personalized directory is the focus of attention for all SySAM activity. This contains the copies of PB.INI, *.LIC, and the properties file that are actually being used. The copies in the original \Program Files\Sybase\... directory are pristine copies from the installation process and are not used.
C.1) PB.INI
The good-old ini file with all the handy settings we are all familiar with. To assist debugging SySAM issues we have introduced a couple new properties.
C.1.1) LogSySAM
Logging is the easiest way to see what is the true nature of the SySAM complaint. This also ensures that you are dealing with the correct location for the license files.
[pb]
LogSySAM = 0 | 1 | 2
(default to zero)
0 := none
1 := normal logging level
2 := yet more logging
Logging creates the file pb110_sysam.log in the same directory. This is typically the first thing that the customer service folks will ask you to do. A quick glance at this file will solve 90% of the SySAM problems.
C.1.2) SySAMTrace
The SySAM trace provides more details about the internals of what SySAM is looking for. I have found this useful when dealing with served licenses.
[pb]
LogSySAM = 1
SySAMTRACE= 0xfffe
This adds a LOT of details (and noise) to the same log file.
C.2) pb110_sysam.properties
The properties file is partially encrypted and partially clear text. This provides information to the licensing system about the type of license to expect and whether the license file is local or from a server. You might be tempted to think that simply changing the "InstalledEdition" to Enterprise that you would be magically elevated. However, this value is used to request the edition license. The request could be refused if the true license is not really an Enterprise license.
C.3) *.LIC - Local File
The true license file, or a reference to the license server. You may have multiple license files (common with ASE and servers, not very common with a tool like PB or PD). These license files are each examined during the startup of the IDE and the first one that satisfies the license request is used. This can sometimes be confusing when you have a beta license or some other condition and things start acting odd.
When you have multiple versions of PowerBuilder installed, things can get confused. An easy way to "eyeball check" the license file, is the version field. This is in the license file on the same line as INCREMENT ...
PowerBuilder and InfoMaker 11.0, 11.1, and 11.2:
INCREMENT PB_xxxx SYBASE 2007.0212
PowerBuilder and InfoMaker 11.5:
INCREMENT PB_xxxx SYBASE 2008.0624
(BTW - since *I* picked the numbers, these are dates important to ME - anniv of first date and wedding anniv. I don't know what I will pick for PowerBuilder 12.0 and PocketBuilder 3.0 but it will be some value that I like...)
C.4) *.LIC - Server Reference
This is a simple reference to the license server. It has no real details because the license server has the true licenses. The licenses fed into the server are similar to the ones above, but the client machine has only a simple "look over there" type of information. A classic server reference is like:
# Generated by PowerBuilder at 2008-Jul-24 11:16:39
# Standalone Seat - Served
SERVER bar.tarfu.com ANY 27000
VENDOR SYBASE
USE_SERVER
There are two common problems I see on the newsgroups, and my typical approach to solve them.
D.1) License failure on IDE startup
This failure is when the IDE displays the license wizard and otherwise refuses to start up. This is typically because the true license from Sybase eShop was never applied or the initialization directory was moved without the license files being (manually!) moved. Knowing the directory details (above) and how to further investigate with the logging should help solve the vast majority of these problems.
D.2) System clock setback detected
This is happens because SySAM also looks around in Windows to make sure the customer has not diddled their system clock to gain extra days (or years!) on a 30 day trial license. However, this can be spurious because of other system tests and even bad applications.
The only solution I've found for this (well, other than formatting the C: drive and reinstalling the OS) is to use an advanced search for all files with a create/modify/access date LATER than today and either 'touch' or simply delete those files.
Of course - if you run PowerBuilder with a future date, then set the clock back, that is detected and you may be permanently locked out.
Note:
For PowerBuilder 11.5 (and probably even 12), the basic technology is the same, but the filenames and directory locations have the expected changes.
This territory has been covered many times for the last dozen years, but I just spent some time to figure out the right API to use, so this may save you (or anybody else) that precious time when you have the same need.
We all know and appreciate that both PowerBuilder and PocketBuilder (and C# and Java) are "managed environments", in other words, the memory and lifetime of objects is all managed for you in a protected universe. However, like C# and Java, you SOMETIMES need to get access to raw memory sitting somewhere out in the computer. The typical case is when you need to handle a message or deal with a DLL API which is not already mapped and handled by the PowerBuilder/PocketBuilder runtime engine.
My current need was driven by a customer request (through professional services in Europe) to be notified when the user clicks the "next month" arrow button on a drop-down calendar control. I knew this came through as a WM_NOTIFY, with the additional values tacked onto the end of the NMHDR structure. Unfortunately, for a multitude of reasons, PowerBuilder (and PocketBuilder) do not have any helper functions when dealing with the WM_NOTIFY message.
The core of dealing with the WM_NOTIFY is to make a local (managed) copy of the memory block that is passed to the message handler simply as a pointer (in the LParam).
This blog item is about copying that memory block from the Windows memory space into a managed structure in the PowerBuilder (or PocketBuilder) application.
First - let's define some local structures (this is all in a UO...)
type str_notify_header from structure
unsignedlong hwnd_from
unsignedlong idFrom
unsignedlong code
end type
Create the functions which would copy the data
// *** Copy the NotifyMessage header locally ***
FUNCTION ulong CopyNMHeader_WIN( REF str_notify_header nmHeader, &
ulong lSourceAddress, ulong cBytes ) &
library "kernel32.dll" alias for "RtlMoveMemory"
FUNCTION ulong CopyNMHeader_CE( REF str_notify_header nmHeader, &
ulong lSourceAddress, ulong cBytes ) &
library "Coredll.dll" alias for "memmove"
To actually use this within the WM_NOTIFY handler. Remembering that PowerBuilder and PocketBuilder do not have customer accessible event handlers for WM_NOTIFY, we have to wedge this into the infamous "OTHER" event.
private constant integer WM_NOTIFY = 78 // 0x004e
private constant integer cb_str_notify_header = 12
event other;
// all window messages flow through this event
long nmCode
str_notify_header nmHeader
IF message.number = WM_NOTIFY THEN
Beep( 1 )
f_log( "WM_Notify: wParam=" + STRING(wParam,"hex8") + &
", lparam=" + STRING(lParam,"hex8") )
IF i_isWinCE THEN
CopyNMHeader_CE( REF nmHeader, lParam, cb_str_notify_header )
ELSE
CopyNMHeader_WIN( REF nmHeader, lParam, cb_str_notify_header )
END IF
// Handle based on the Notify Code
nmCode = nmHeader.Code
f_log( ".. NM.Code=" + STRING(nmCode) )
CHOOSE CASE nmCode
CASE MCN_SELCHANGE, MCN_SELECT
... etc ...
As you can see, the "nmHeader" structure contains the contents that were copied in from the location pointed to by the "lParam" passed in by the Windows call.
PowerBuilder also has the ability to properly "marshall" the data from nested structures, however PocketBuilder seems to be trapped a bit by the different memory alignment considerations on the ARM and the X86 CPUs.
Looking into the contents of PowerBuilder types is an area that is not well explored by most people (well, except for maybe Terry, Mr. PBL Peeper). A new person in the PB technical documentation group asked me a question that required some exploring, so I am sharing...
The question was basically - "At RUNTIME - how can I see the values of an enumeration"....
This requires the use of the EnumerationDefinition and EnumerationItemDefinition types built into PowerBuilder.
A simple example to see the values in the built-in enumeration "Alignment"...
First - on a command button...
EnumerationDefinition ed
ed = FindtypeDefinition( "Alignment" )
f_log( ed )
And the specific "f_log" which dives into the type...
public subroutine f_log (EnumerationDefinition a_ed);
// log the contents of the enumeration definition
integer idx
EnumerationItemDefinition eid
// type Definition
f_log( "**** Enumeration Definition ****")
f_log( "Name: " + a_ed.Name )
f_log( "DataTypeOf: " + a_ed.DataTypeOf )
f_log( "isSystemType: " + string(a_ed.isSystemType) )
f_log( "LibraryName: " + a_ed.LibraryName )
// the contained variables
for idx=1 to UpperBound(a_ed.Enumeration)
// each item of the enumeration
eid = a_ed.Enumeration[ idx ]
f_log( "Enum Item[" + string(idx) + "]" )
f_log( " Name: " + eid.Name )
f_log( " Value: " + string(eid.Value) )
next
end subroutine
This results in the following output (the "f_log(string)" results)....
**** Enumeration Definition ****
Name: alignment
DataTypeOf: alignment
isSystemType: true
LibraryName: pbvm115.dll
Enum Item[1]
Name: right
Value: 2
Enum Item[2]
Name: left
Value: 0
Enum Item[3]
Name: justify
Value: 3
Enum Item[4]
Name: center
Value: 1
The IDE and Runtime Update for PocketBuilder, version 2.5.1 (build 1155) is now available from
http://downloads.sybase.com
This EBF is for both the IDE and device side of the product.
The updates include:
In the PocketBuilder tradition, this is a "rollup" of all previous along with new bug fixes and features.
One thing to note - this is just a ZIP file - simply unzip it.
No "setup.exe" or other installers to mess with...
Note:
This was published the day BEFORE Friday the 13th.
Just saw a press release - Sybase and Sun have set a "Guinness World Record" for the worlds largest data warehouse.
"One Petabyte of mixed relational and unstructured data—more than 34 times larger than the largest industry standard benchmark and twice the size of the largest commercial data warehouse known to date ... In total, the data warehouse contains six trillion rows of transactional data and more than 185 million content-searchable documents, such as emails, reports, spreadsheets and other multimedia objects."
mmmmmmm - Petabyte - a thousand terabytes - a million gigabytes....
Ages ago, my wife worked on an early terabyte sized database for a bank in Florida (all managed in PowerBuilder of course - yes - PowerBuilder geekness is "in the family").
PocketBuilder 2.5.1 is getting some new samples from our evangelist Ian Thain (with the documentation written by yours truly). We have added:
Interesting. Thanks friend!
