Monday, August 26, 2013

DATEDIFF Mistakes Case Study 2: Foxhound


Previously on . . . Documenting DATEDIFF described how the peculiar workings of SQL Anywhere's DATEDIFF() function can lead to coding errors, and DATEDIFF Mistakes Case Study: This Blog was a bug hunt for those errors in some sample code.

Now the bug hunt continues, this time in production code for an application that depends heavily on DATEDIFF(): the Foxhound performance monitor.
An early design decision is reflected in the code throughout Foxhound: All time intervals are calculated in milliseconds, even long intervals measured in seconds, hours or even days. As a result, even though DATEDIFF ( MILLISECOND, x, y ) is often called with TIMESTAMP values for x and y, and even though that can result in an error of (almost) one whole millisecond in the value returned by DATEDIFF, it doesn't matter: Foxhound only displays intervals to the nearest 0.1 second, so an error of 0.001 second doesn't affect the result.

Here's an example; the internal Foxhound function rroad_f_msecs_as_d_h_m_s() takes a BIGINT value in milliseconds and formats it to return a string like '1h 16m 56s' or '9.9s'
rroad_f_msecs_as_d_h_m_s ( DATEDIFF ( MILLISECOND, active_alert.recorded_at, @current_timestamp ) ),
Only small values (less than one hour) are shown to the nearest tenth of a second, like '9.9s', and large values are only shown to the nearest second like '1h 16m 56s', so DATEDIFF errors of one millisecond or less don't matter.

Foxhound is awash in DATEDIFF MILLISECOND calls, and they all share the same characteristic: The errors don't matter because the code doesn't care about milliseconds. Foxhound isn't a financial application that cares about the pennies, it isn't even an execution profiler that cares about how long a single statement takes to execute; it is a performance monitor that gathers samples every 10 seconds.


Are there any DATEDIFF something-other-than-MILLISECOND calls in Foxhound?

Yes, there are a few. This one checks a user input datetime for validity:
WHEN DATEDIFF ( DAY, @FOXHOUND3UPGRADE_timestamp, CURRENT TIMESTAMP ) > 100000 THEN
A @FOXHOUND3UPGRADE_timestamp value more than 100,000 days in the future is ignored because it is "way too big". Since DATEDIFF DAY counts the number of day boundaries between the two timestamps, the return value could be wrong by (almost) one entire day, which means a value only 99,999 days in the future could be incorrectly rejected.

Yeah, that's a bug... one that's not going to be fixed, or even documented in the Foxhound FAQ, but a bug nonetheless... the Foxhound Development Team promises to do better!


Here's another example; DATEDIFF DAY is called calculate how many days are left before the current rental period expires:
IF  @edition_name = 'Rental'
AND @expiry_date < '9999-12-31' THEN

   SET @rental_period_will_end_in_days = DATEDIFF ( DAY, CURRENT DATE, DATEADD ( DAY, 1, @expiry_date ) );

ELSE

   SET @rental_period_will_end_in_days = 9223372036854775807; -- never ends; i.e., it's not a rental

END IF;
In this case, the second and third arguments to DATEDIFF are only precise to the nearest DAY, so counting the number of day boundaries is the same as counting the number of days, and DATEDIFF DAY returns the right answer.

What's the score?

Here's how DATEDIFF usage is scored according to the previous Case Study:
  • FAIL means the DATEDIFF usage is badly flawed; it shouldn't have been coded that way, and it should be fixed.

  • LUCKY means the DATEDIFF usage may be flawed but it doesn't matter given the data values involved.

  • OK means the DATEDIFF usage is OK given the data types involved.
Foxhound gets a LUCKY for all those DATEDIFF MILLISECOND calls where the errors don't matter (the first example above), a FAIL for the DATEDIFF DAY bug that rejects 99,999 as being "way too big", and an OK for the DATEDIFF DAY calculation involving the expiry date.

This bug hunt didn't turn up anything worth changing... like all bug hunts it did find some stuff in need of fixing, just not DATEDIFF :)

Monday, August 19, 2013

Latest SQL Anywhere Updates: Windows 12.0.1.3942

Current builds for the active platforms...

HP-UX     16.0 GA Dev Edition download       (date n/a)      Dev Edition registration
 Itanium  12.0.1.3894 Update                 16 May 2013
          11.0.1.2958 Update                 08 Apr 2013     End of Life 31 May 2014

IBM AIX   16.0 GA Dev Edition download       (date n/a)      Dev Edition registration
          12.0.1.3894 Update                 16 May 2013
          11.0.1.2958 Update                 08 Apr 2013     End of Life 31 May 2014

Linux     16.0.0.1535 Update                 30 May 2013
          12.0.1.3873 Update                 05 Apr 2013
          12.0.1 Chinese,                    16 Apr 2013
                 Japanese Docs (Eclipse)     16 Apr 2013
          11.0.1.2958 Update                 08 Apr 2013     End of Life 31 May 2014

Mac OS    16.0.0.1535 Update                 09 Jul 2013
          12.0.1.3901 Update                 23 May 2013
          11.0.1.2449 Update                 29 Jun 2010     End of Life 31 May 2014

Solaris   16.0 GA Dev Edition download       (date n/a)      Dev Edition registration
 SPARC    12.0.1.3894 Update                 16 May 2013
          11.0.1.2958 Update                 08 Apr 2013     End of Life 31 May 2014

Solaris   16.0 GA Dev Edition download       (date n/a)      Dev Edition registration
 x64      12.0.1.3894 Update                 16 May 2013
          11.0.1.2958 Update                 08 Apr 2013     End of Life 31 May 2014

Windows   16.0.0.1535 Update                 30 May 2013
          12.0.1.3942 Update             *** 15 Aug 2013 ***
          12.0.1 French,                     25 Sep 2012
                 English,                    25 Sep 2012
                 German,                     25 Sep 2012
                 Chinese,                    28 Mar 2013
                 Japanese Docs (HTML/PDF)    28 Mar 2013
          11.0.1.2960 Update                 16 Apr 2013     End of Life 31 May 2014 

Other Stuff...

 Older Updates

 Free support! Q&A forum
   ...or, call Tech Support

 SQL Anywhere...
   ...Sybase home page 
   ...SAP home page 
   ...SAP Developer Center 

 Buy SQL Anywhere 

 Developer Edition... 
   [16.0] [12.0.1] [11.0.1]

 Download the...
   Educational Edition 
   Web Edition 

 Supported Platforms...
   SQL Anywhere 
   Linux 
   OnDemand

 ODBC Drivers for MobiLink

The asterisks "***" show which items have appeared on the Sybase website since the previous version of this page.
  • Only the latest fully-supported versions of SQL Anywhere (11.0.1, 12.0.1 and 16.0) are shown here.

  • Just because an older version or different platform isn't "fully supported" any more doesn't mean you can't download files (or ask questions, or get help), it just means there won't be any more new Updates released.

Wednesday, August 14, 2013

The WaybackGlennMachine

Once upon a time, there were two regularly-published blogs devoted to SQL Anywhere: this one, and a better one written by Glenn Paulley. Before leaving SAP on July 31, 2012, Glenn had published over 150 posts of a technical nature as well as many announcements and other posts.

Sadly, as part of the transition to the SAP Community Network, Glenn's blog and four others (Chris Kleisath, Eric Farrar, Jason Hinsperger and Tom Slee/Philippe Bertrand) were suddenly wiped from existence, taking with them over 300 posts containing valuable technical information.

A handful of Glenn's posts have been republished on the SAP Community Network, but it's clearly not a high priority task.

The Internet Midden To The Rescue!


The good news is, you can still find most of Glenn's posts in The Wayback Machine. It helps if you know what you're looking for, and the Technical Documents page on this blog can help as follows:
  1. Scroll through the Technical Documents page looking for "Glenn Paulley" entries marked "Blog: ..."

  2. When you find one you like, click right mouse - Copy link address on the title:

  3. Open up The Wayback Machine and paste the link address into the "Take Me Back" field:

  4. Click on "Take Me Back" button to see a calendar of all the different times Glenn's post was archived.

  5. Click on any of the calendar entries for that post; it doesn't matter which one because Glenn wasn't in the habit of changing old posts.

  6. Here's what you'll see, an almost-fully-functional copy of the original post:

Sure, it's a kludge...


Some of Glenn's posts are missing, and some of the embedded objects too, and some of his links have rotted.

And no, Google search doesn't reach into The Wayback Machine.

But... it's better than the alternative:

Dilbert.com 2010-12-11

Monday, August 12, 2013

Characteristic Errors, Revision 4

UPDATE: See the latest version of this article here.


Back in June this list had 35 entries, now it has 42...

[click here to see the new entries]

A characteristic error is an error that is so easy to make that it appears you are being actively encouraged to make it by the very nature of the computer program you are using.

For example, sending an email without the attachment is a characteristic error of all email programs.
...except Gmail. Gmail warns you about missing attachments... Gmail is magic!
Here are some errors that are characteristic of SQL in general, SQL Anywhere in particular, and some companion programs.
  1. SQL: Seeing too little data, or no data at all, because a predicate in the WHERE clause effectively turned your OUTER JOIN into an INNER JOIN.

  2. SQL: Seeing too much data because a missing predicate effectively turned your INNER JOIN into a CROSS JOIN.

  3. SQL: Getting the wrong COUNT() or SUM() because you forgot to code WHERE ... IS NOT NULL, or you *did* code it when you shouldn't have.

  4. SQL: Getting the wrong answer because you forgot that, in general, NULL values [cough] suck.

  5. SQL Anywhere: Not seeing MESSAGE output because you forgot to run SET TEMPORARY OPTION DEBUG_MESSAGES = 'ON';

  6. SQL Anywhere: Not seeing any data because you forgot ON COMMIT PRESERVE ROWS or NOT TRANSACTIONAL.

  7. SQL Anywhere: Coding ENDIF where END IF was required, or vice versa (before Version 11).

  8. SQL Anywhere: Connecting to the wrong server because you forgot DOBROAD=NONE (before Version 12).

  9. SQL Anywhere: Forgetting the asterisk in SELECT TOP 10 FROM ...

  10. SQL Anywhere: Coding IF NOT VAREXISTS ( 'x' ) THEN ... instead of IF VAREXISTS ( 'x' ) = 0 THEN ...

  11. SQL Anywhere: Coding the wrong magic numbers 1, 2, 3, ... in the get_value() and set_value() calls in an EXTERNAL C DLL function.

  12. SQL Anywhere: Getting proxy table ODBC errors because the engine's running as a service and you've set up a User DSN instead of System DSN.

  13. SQL Anywhere: Getting file-related errors because the file specifications are relative to the server rather than the client.

  14. SQL Anywhere: Getting file-related errors because the engine's running as a service without the necessary permissions.

  15. SQL Anywhere: Coding CREATE TRIGGER IF NOT EXISTS instead of CREATE OR REPLACE TRIGGER, or vice versa for CREATE TABLE (in 11.0.1 or later).

  16. SQL Anywhere: Getting integer arithmetic when you wanted fractional parts because you forgot to CAST.

  17. Stored procedure debugger: Setting it to watch a specific user id other than the one you're using to test your code.

  18. Sybase Central: Setting it to display objects for owner names other than the one you're interested in.

  19. Copy and paste: Forgetting to edit after pasting; e.g., Copy and paste SET @continue = 'Y' into the body of a WHILE loop and then forgetting to change it to 'N'.

  20. MobiLink: Forgetting to call ml_add_column for any of the columns you're trying to synchronize, thus guaranteeing yourself a "Sassen Frassen Fricken Fracken!" moment when you run the first test.

  21. MobiLink: Forgetting to call ml_add_[various] with the NULL parameter to delete old ml_[whatever] rows, thus ending up with thousands of orphan system table rows in the consolidated database.

  22. OLAP Windowing: Coding the wrong combination of ASC and DESC in an inner OVER ORDER BY clause and the outer SELECT ORDER BY: different when they should be the same, the same when they should be different, or some other variation of "wrong combination"...
                SELECT older_sample_set.sample_set_number
                  INTO @20_older_sample_set_number
                  FROM ( SELECT TOP 20
                                ROW_NUMBER() OVER ( ORDER BY rroad_sample_set.sample_set_number ASC ) AS scrolling_row_number,
                                rroad_sample_set.sample_set_number                                    AS sample_set_number
                           FROM rroad_sample_set
                          WHERE rroad_sample_set.sampling_id       = @sampling_id
                            AND rroad_sample_set.sample_set_number < @sample_set_number
                          ORDER BY rroad_sample_set.sample_set_number DESC ) AS older_sample_set
                 WHERE older_sample_set.scrolling_row_number = 20;

  23. MobiLink: Forgetting to call ml_add_column() when trying to use named parameters instead of "?" in versions 10 and 11 MobiLink scripts, resulting in a "What the ... ? Sassen Frassen Fricken Fracken!" moment during the first test (thank you, Jeff Albion).

  24. SQL: Omitting a PRIMARY KEY column from the WHERE clause, thus turning a singleton SELECT (or DELETE!) into something rather more enthusiastic than expected (thank you, Ron Hiner).

  25. HTTP web services: Leaving an & in the code when a ? is required, and vice versa, when editing service URLs; e.g., 'HTTP://localhost:12345/web_service&service_parm2=!parm2'

  26. SQL Anywhere: Forgetting that not all functions look like functions: SELECT CAST ( CURRENT TIMESTAMP, VARCHAR )

  27. Batch file: Trailing spaces on SET commands; e.g., SELECT CAST ( xp_getenv ( 'DEBUG_MESSAGES' ) AS VARCHAR ) returns 'OFF ' instead of 'OFF' after SET DEBUG_MESSAGES=OFF
  28. Forum: Clicking Reply on the main Question or Answer entry instead of the comment you wanted.

  29. SQL Anywhere: Forgetting to run dblog to tell the database file where the log is now, after moving the database and log files to a different folder (thank you, Justin Willey).

  30. SQL Anywhere: Having to look up WAIT in the Help ... every ... single ... time, to be reminded that's it's WAITFOR, not WAIT.

  31. SQL: Forgetting to check the SELECT against the GROUP BY, resulting in "Function or column reference to ... must also appear in a GROUP BY" (thank you, Glenn Paulley).

  32. SQL: Coding too much in the GROUP BY (like, say, the primary key) so every group contains but a single row (thank you, Glenn Paulley).

  33. Design: Forgetting to accomodate or prevent loops in a tree structure, resulting in a tree traversal process that pegs the CPU at 100%... forever (thank you, Ove B).

  34. MobiLink: Unwittingly using a variety of user ids when running sync*.sql, updating MobiLink scripts and running the MobiLink server, resulting in inexplicable inconsistencies.

  35. MobiLink: Accidentally creating multiple script versions and then getting them crossed up when updating MobiLink scripts and running the MobiLink client.


    New entries...

  36. SQL Anywhere: Forgetting to run the 32-bit version of SQL Anywhere when working with Excel proxy tables.

  37. ODBC Administrator: Running the 64-bit version (huh?) of odbcad32.exe (say what?) when you need 32-bit version at C:\WINDOWS\SysWOW64\odbcad32.exe (oh, fer #*@&!!!)

  38. ODBC Administrator: Forgetting to click OK ... twice ... to actually save your new ODBC DSN after celebrating your success with Test Connection.

  39. ODBC Administrator: Setting up an ODBC DSN on the wrong computer: "It goes with the client!" ... but sometimes it's not obvious where the client is actually located.

  40. Security: Forgetting which Windows user id you're using on which system, then spending too much time with Windows menus, firewall software and Google searches before the "Doh!" moment.

  41. SQL: Getting an exception that is not only completely inexplicable, but absolutely impossible for the statement that raised it... until you think to look inside the triggers.

  42. SQL Anywhere: Getting an exception because a FOR loop variable has a scope conflict with a column name, or worse, NOT getting an exception, just a wrong result.



Friday, August 9, 2013

DATEDIFF Mistakes Case Study: This Blog

After writing about problems with DATEDIFF it seems natural to look for examples, and there's no more exciting place to start throwing stones than inside one's own glass house!

And so we have . . .

Dogfooding DATEDIFF

. . . a critical look at the use and abuse of SQL Anywhere's DATEDIFF function in this blog.

In other words, a Bug Hunt, with each example of DATEDIFF ranked as follows:
  • FAIL means the DATEDIFF usage is badly flawed; it shouldn't have been coded that way, and it should be fixed.

  • LUCKY means the DATEDIFF usage may be flawed but it doesn't matter given the data values involved.

  • OK means the DATEDIFF usage is OK given the data types involved.
That last point about data types is interesting; it isn't discussed in the Help, it wasn't mentioned in Documenting DATEDIFF, and it makes this Bug Hunt all the more worthwhile.


Example 1 is OK: Let's play "Gotcha!" - Round Two

All the examples share one characteristic in common: The second and third DATEDIFF arguments (the date/time values) are no more precise than the first argument (the unit name). In other words, DAY is used on dates with no time component, and SECOND is used on timestamps that don't have fractional seconds.
SELECT DATEDIFF ( DAY, '2011-09-28', '2011-09-29' );
SELECT DATEDIFF ( SECOND, '2011-09-28 23:59:58', '2011-09-28 23:59:59' );
SELECT DATEDIFF ( SECOND, '7910-12-31 23:59:58', '7910-12-31 23:59:59' );
SELECT DATEDIFF ( SECOND, '7910-12-31 23:59:59', '7911-01-01 00:00:00' );
As a result, they all give correct results.

Well, the first 3 do, and the last one would have worked if the third argument hadn't been out of range (the whole point behind the article :).


Example 2 is OK: Let's play "Gotcha!" - Round Three
DATEDIFF ( SECOND, '2011-09-28 23:59:58', '2011-09-28 23:59:59' )
DATEDIFF ( SECOND, '7910-12-31 23:59:58', '7910-12-31 23:59:59' )
DATEDIFF ( SECOND, '6910-12-31 23:59:58', '7910-12-31 23:59:59' )
No DATEDIFF problems here at all, for the same reason: All the timestamps are precise only to the second.


Example 3 is LUCKY: Intra-Procedure Parallelism

There are a couple of problems with these DATEDIFF calls:
...
DECLARE @start        TIMESTAMP;
DECLARE @start_step_1 TIMESTAMP;
DECLARE @start_step_2 TIMESTAMP;
...
SET @start        = CURRENT TIMESTAMP;
SET @start_step_1 = CURRENT TIMESTAMP;
...
MESSAGE STRING ( CAST ( DATEDIFF ( MILLISECOND, @start_step_1, CURRENT TIMESTAMP ) 
                        AS DECIMAL ( 11, 2 ) ) / 1000.0,
                 ' seconds to perform step 1' ) TO CONSOLE;
...
SET @start_step_2 = CURRENT TIMESTAMP;
...
MESSAGE STRING ( CAST ( DATEDIFF ( MILLISECOND, @start_step_2, CURRENT TIMESTAMP ) 
                        AS DECIMAL ( 11, 2 ) ) / 1000.0,
                 ' seconds to perform step 2' ) TO CONSOLE;

MESSAGE STRING ( CAST ( DATEDIFF ( MILLISECOND, @start, CURRENT TIMESTAMP ) 
                        AS DECIMAL ( 11, 2 ) ) / 1000.0,
                 ' seconds to perform both steps' ) TO CONSOLE;
...
10.1680000 seconds to perform step 1
19.9700000 seconds to perform step 2
30.1440000 seconds to perform both steps
First, the calls may return values that are incorrect by up to one millisecond because DATEDIFF MILLISECOND returns the number of millisecond boundaries between the two timestamps.

Second, since DATEDIFF MILLISECOND returns a BIGINT, the CAST is singularly pointless, possibly dangerous: You can't magically add two digits of precision to an integer, and DECIMAL ( 11, 2 ) isn't big enough for a BIGINT:
SELECT CAST ( 9223372036854775807 AS DECIMAL ( 11, 2 ) );

Value 9223372036854775807 out of range for destination
SQLCODE=-158, ODBC 3 State="22003"
But wait! There's no way this code will run long enough overflow a DECIMAL ( 11, 2 ), and the CAST is there to force decimal rather than integer division. The division by 1000.0 indicates that the user is interested in seconds, rather than milliseconds.

In other words, DATEDIFF MILLISECOND is being used to increase accuracy, not decrease it... an error of one millisecond is OK whereas DATEDIFF SECOND might have an error of a whole second.

The code's not wrong, but it is a bit sloppy: The output shows 7 digits of precision to the right of the decimal point whereas the actual values are only precise to the second digit. An outer CAST AS DECIMAL ( 11, 2 ) call could be used to show this... or call to ROUND().


Example 4 is OK: Today's Tip: Counting Days of the Week

The code is OK because "number of day boundaries" is the same as "number of days" when you're talking about dates with no time component:
DATEDIFF ( DAY, '2007-12-14', '2008-01-29' )
Even the explanation in the article is OK, in this particular case: "The DATEDIFF ( ... ) call returns the number of days between the two dates."


Example 5 is a FAIL: I'm lonely! signed, Your Database

This code uses DATEDIFF SECOND on full-precision timestamps, so it can return a value that may be up to one second too large because it counts the number of second boundaries between the two timestamps, not the number of seconds difference.

In this example, that means a repeated email may be sent in 19 seconds rather than 20:
...
DECLARE @email_sent_at                       TIMESTAMP;
DECLARE @current_timestamp                   TIMESTAMP DEFAULT CURRENT TIMESTAMP;
...
DECLARE @email_repeat_threshold_in_seconds   BIGINT DEFAULT 20;
...
      SELECT email_sent_at
        INTO @email_sent_at
        FROM lonely; 

      IF DATEDIFF ( SECOND, @email_sent_at, @current_timestamp ) 
            >= @email_repeat_threshold_in_seconds THEN  
...

Maybe a 5% error doesn't matter, or even a 10% error (if the DEFAULT was 10 instead of 20), but that's not the point... the author (me) didn't realize the implications of using DATEDIFF SECOND on precise timestamp values.

Not knowing is not good, not in this business.


Example 6 is OK: Everything Looks Like a Database

This one is ok, a DATEDIFF DAY on two dates that don't contain time components:
...
DECLARE @from_date DATE;
DECLARE @to_date   DATE;
SET @from_date = '2009-02-01';
SET @to_date   = '2009-12-31';
...

             DATEDIFF ( DAY, @from_date, @to_date ) ) )
...


Example 7 is LUCKY: Capturing the Server Console Log

Here's an example of a DATEDIFF call that can return values that are too large by up to one millisecond:
...
DECLARE LOCAL TEMPORARY TABLE checkpoint_record (
   checkpoint_starting   TIMESTAMP NOT NULL PRIMARY KEY,
   checkpoint_finished   TIMESTAMP )
   NOT TRANSACTIONAL;
...
SELECT *,
       DATEDIFF ( MILLISECOND, 
                  checkpoint_record.checkpoint_starting,  
                  checkpoint_record.checkpoint_finished ) AS msec
  FROM checkpoint_record
 ORDER BY checkpoint_record.checkpoint_starting;
...
checkpoint_starting      checkpoint_finished      msec
2011-01-30 05:11:32.000  2011-01-30 05:11:32.281   281
2011-01-30 05:31:33.453  2011-01-30 05:31:33.937   484
2011-01-30 05:51:35.046  2011-01-30 05:51:35.515   469
2011-01-30 06:11:36.640  2011-01-30 06:11:37.078   438
2011-01-30 06:31:38.234  2011-01-30 06:31:38.781   547
2011-01-30 06:51:39.937  2011-01-30 06:51:41.125  1188
With these particular values one second is an error of 0.3% to 0.08%... which is probably OK.

The point, however, is the same as before: One shouldn't use DATEDIFF MILLISECOND if one wants millisecond accuracy.


Example 8 is OK: Great Moments In History: Housing Bubble

The code in this post uses DATE values with no time components, so DATEDIFF DAY works just fine:
       DATEDIFF ( DAY, first_date, last_date ) AS days,


It could be said the scoring is too lenient: Given the ignorance factor all the OK scores should really be marked as LUCKY. And maybe, all the LUCKYs should be FAIL.

Dilbert.com 1991-08-11

Wednesday, August 7, 2013

TechEd 2013 Session Catalog - Updated

25 sessions have recently appeared in the MOB (Mobile) track in the TechEd 2013 Session Catalog, but none of them mention SQL Anywhere or MobiLink in either the title or description.

SELECT COUNT ( DISTINCT Session_ID )  
  FROM SessionDownload2
 WHERE Session_ID LIKE 'MOB%' 
   AND (    Title       LIKE '%MobiLink%'
         OR Title       LIKE '%SQL Anywhere%'
         OR Description LIKE '%MobiLink%'
         OR Description LIKE '%SQL Anywhere%' );

COUNT 
-----  
    0 
Here are all the new MOB titles...
Session_ID Title                                                                                                
---------- ---------------------------------------------------------------------------------------------------- 
MOB100     Understand How SAP Mobile Platform Solves Enterprises' Mobility Needs                                
MOB101     Syclo Agentry for SAP Mobile Professionals                                                           
MOB102     Mobile Application Development with SAP HANA Cloud Platform                                          
MOB103     SAP runs SAP – Mobile security with SMP & SAP Afaria                                                 
MOB105     Customer Success with the SAP Machine-to-Machine Platform                                            
MOB106     Deploy the SAP Mobile Platform in Weeks with SAP Rapid Deployment Solutions                          
MOB107     Using SAPUI5 in Mobile Application Development                                                       
MOB108     Rapid Application and Service Development with SAP Mobile Platform 3.0                               
MOB109     Co-Innovate with SAP Experts to Develop Consumer-Grade Mobile Solutions                              
MOB111     How to Build and Design Mobile Enterprise Applications                                               
MOB113     Mobile or Immobile?                                                                                  
MOB114     How Newell Rubbermaid Uses Mobile Applications to Improve Quality and Sales                          
MOB115     Using SAP Mobile Solutions, SAP Afaria, and a Rapid-Deployment Solution to Manage Product Location  
MOB116     Enabling Mobile Access to SAP – Design Decisions and Lessons Learned                                 
MOB117     Mobile Platform Design & Management Overview                                                         
MOB118     Secure Mobile Content Management with SAP Mobile Documents                                           
MOB119     Tackling Mobile Security – Deep Dive into SAP Afaria                                                 
MOB202     Creating Services for Mobile Applications Using SAP NetWeaver Gateway OData Channel                  
MOB203     Rapid Mobile Deployment with SAP NetWeaver Gateway and Adobe PhoneGap                                
MOB260     Mobilizing SAP HANA with SAP Mobile Platform                                                         
MOB261     Build an enterprise mobile application on SAP Mobile Platform                                        
MOB262     Build a Process Driven Mobile Application on the SAP Mobile Platforrm                                
MOB263     Building an E2E Solution with SAP Mobile Platform Against a Non-SAP Backend                          
MOB264     Learn How to Build Mobile Solutions to Integrate with CTS+ and SAP Solution Manager                  
MOB840     Secure Mobile Content Management with SAP Mobile Documents                                           
Here's the list of sessions that DO touch on SQL Anywhere and MobiLink:
Session_ID Title                                                                                                
---------- ---------------------------------------------------------------------------- 
RDP109     Orbiting the Enterprise – SAP Sybase SQL Anywhere as a Satellite Server                              
RDP118     Introduction to SAP Sybase SQL Anywhere                                                              
RDP119     SAP Sybase SQL Anywhere Satellite Database Case Studies                                              
RDP121     Best Practices for Embedding Databases in Lines of Business Applications                             
RDP122     Enhancing Business Intelligence Deployments with SAP Real-Time Data Platform                         
RDP124     Getting Started with SAP Sybase SQL Anywhere, On-Demand Edition                                     
RDP141     Powerful Data Access at the Edge of the Enterprise                                                   
RDP220     Mobilizing Data-Driven Applications                                                                  
RDP222     OData Support in SAP Real-Time Data Platform                                                         
RDP278     Extending SAP HANA to SMEs Using SAP Sybase SQL Anywhere and MobiLink                                
RDP868     SQL Anywhere Road Map for Mobile and Embedded Systems                                                
TEC101     How to Best Embed SAP Technology 
RDP868 is new on this list, replacing EA269 (Everything You Need to Know to Use SAP Crystal Reports) which is still being offered but the description no longer mentions SQL Anywhere or MobiLink.

So, the count is still 12... is that enough to get you to Las Vegas?

Are you interested in HANA?
SELECT COUNT ( DISTINCT Session_ID )  
  FROM SessionDownload2
 WHERE Title       LIKE '%HANA%'
    OR Description LIKE '%HANA%';
  
COUNT
----- 
  229 


Friday, August 2, 2013

TechEd 2013: Last Day for Early Bird Rate

Today (August 2) is the last day for the Early Bird rate at the SAP TechEd 2013 conference in Las Vegas on October 21 to 25.



Dilbert.com 1998-07-09