1. Self Hosted – You host the hardware and manage the data
   This is the traditional scenario. You own and manage your hardware in your office space and all of your data resides on this hardware. You are responsible for maintenance and upkeep of the hardware, as well and maintenance of all software and files on the machine, including your database backups.
   You know where your data is physically located, and can get to it at a moments notice. Taking care of the hardware/software is not core to your business, but is required to maintain complete control of your data.
2. Co-location Hosted – You place hardware at a co-lo and manage the data
   The next step is locating hardware you buy at a managed site, where the site takes care of the hardware maintenance and upkeep for you, for a fee. You are still responsible for all software on the machine, the maintenance of your database (including backups) and the replacement/upgrade of any hardware.
   You know where your data is physically located, but it would take time to get to it.
   This takes care of hardware management, which is generally not considered to be core to a business, allowing you to focus resources on more important things. However, there are still non-core activities you must engage in to maintain control of your data (eg. hardware replacement/upgrades).
3. Co-location Rented – You rent the hardware at a co-lo and manage the data
   In this scenario, you rent hardware at a managed site, where you pay for specific resources (CPU, disk, memory). The site provides you with those services on one or more machines, and maintains those machines for you. You are responsible for the software on the machine, including your database, but backups (and recovery) are handled by the co-lo provider.
   You have a good idea of where your data is physically located, but perhaps not at any exact moment in time, since it may move within the co-lo facility as conditions change (eg. hardware failure or replacement).
   At this point, all hardware management activities are taken care of for you, leaving you to deal with the software you require to run your business.
4. Computing Service ProviderYou pay for hosted service and manage the data
   In this case you rent specific services from a service provider (CPU, RAM, disk, operating system). The service provider manages the hardware and maintains the OS. You only have to manage any software specific to your business, which includes your database. However, the service provider usually manages backup and recovery of your data for you as part of the service.
   Outside of a specific (and more expensive) agreement with the service provider, you don’t know where your data is physically located at any point in time, since the service provider is free to place it anywhere in any of their data centres that can provide the service you are paying for.
   However, you are getting rid of the need to manage much of the software needed to run your business, and increasing your ability to stay available, leaving you to maintain only the data and data management software.
5. Complete Service ProviderYou pay for hosted service and data
   In this case you rent all services from a service provider. The service provider manages the hardware, maintains the OS, and provides access to the software you need, usually via web services. You only have to access the service to manage your data.
   Again, short of a specific (and likely expensive) agreement with the service provider, you don’t know where your data is physically located at any point in time, since the service provider is free to place it anywhere in any of their data centres that can provide the service you require.
   You have effectively gotten rid of all hardware, software and data management requirements at this point. All you need to do is put data into the system, and get data out of the system, in specific formats as specified by the service provider application.

SQL Anywhere OnDemand, currently available in beta, takes a fundamentally different approach to database management for SaaS applications, based on the following key assumptions about ISV customers:

• Customers running an ISV application usually have no relationship with each other
• Customers running an ISV application usually do not want to share their data with other customers of that ISV
• Different customers have different usage patterns, performance and service-level requirements

Most current database management offerings that support SaaS deployments, use a single database/server, and use replication, sharding and other methods to scale that database to match customer demands. However, this method is inherently flawed as a solution for ISVs looking to offer a SaaS application for several reasons:

• A single database server model prevents an ISV from capitalizing on the key customer assumptions made above. For example, under the single database/server model, all tenants are impacted by any change made to your environment to address any change in requirements from a single tenant.
• The complexity of this implementation is expensive and error prone.
• Managed together, tenant data could potentially be exposed to other tenants in a variety of ways.

Worse yet is using a data-as-a-service provider – in addition the above problems, in this model ISVs have little or no control over the customer experience with their application, which makes it difficult (and sometimes impossible) to address entire classes customer problems and concerns (eg. performance problems).
In the end, using a single, monolithic database/server to manage all tenant database(s) in a SaaS environment does not make sense.

Given the above ISV customer assumptions, it does makes sense to have a single database for each of your customers. This allows you the maximum amount of flexibility in terms of

• Keeping tenant data separate
• Providing different levels of service (related to performance, availability, extra functionality etc…)
• Dealing with the demands of those customers with larger databases without impacting other tenants.
• Limiting the impact of infrastructure changes to a single tenant, or at most a small number of tenants

From a management perspective, having a single database for each customer means dealing with hundreds, or even thousands of individual tenant databases. Maintaining availability, doing backups, validating, etc… is a huge job. This is where SQL Anywhere OnDemand comes in. SQL Anywhere OnDemand allows an ISV to scale the database management layer by the number of databases. It provides an infrastructure layer that can help to manage thousands of individual tenant databases. This means that each tenant can have their own database, which provides many advantages, and allows the ISV to easily manage the administration of those databases.

By using the existing strengths of SQL Anywhere, the OnDemand console allows an ISV to manage each customer in an individual tenant database. Tenant databases can be managed individually or in groups, allowing you to do things like

• Move a specific tenant database from a loaded server to one with less activity,
• Send out an upgrade script to an entire group of tenants.
• Backup and restore an individual tenant database
• Bring new resources (hosts, database servers) online (and take them offline) as customer usage patterns and requirements change.
• Restrict where a tenant database can be physically stored

The tenancy model of SQL Anywhere OnDemand is ideally suited for ISV’s looking to offer SaaS solutions to the market.

“What changes should I make to my database to make it faster?”

“What should the specs be on my server machine that will run SQL Anywhere?”

“My application is slow. How can I make it faster?”

The answer to all of these questions is:

No really, the answers to all of these questions depends on things like:

• Number of users
• Size of database
• Database architecture
• Application design
• Expected usage pattern
• Identification of existing bottlenecks
• etc…

A great place to start learning about various aspects of performance is with some of the papers listed on Glenn Paulley’s blog, and from our webcast archives.

There is no magic bullet, no magic “go fast” option for the database server. SQL Anywhere does a fantastic job of utilizing whatever resources are available to their full extent, dynamically adjusting as things (eg. machine workload, database workload, etc…) change. However, if you want to improve performance, you are going to have to put in some time analyzing and determining what changes should be made to get you the biggest bang for your buck. If you don’t, you risk spending wasting money on things that may have little or no impact on performance.

The above information, formatted to fit the situation, is my stock response every time the performance question comes in. Inevitably, I get the follow-up question which boils down to “Please give us some something.”

I understand why these questions come in. SQL Anywhere supports a wide variety of operating environments and has relatively low minimum requirements. In turn, our customers, who embed SQL Anywhere in their solutions, have to support a variety of end-user environments. They need to provide some sort of initial guidance to their end customers to ensure a positive experience with their applications.

Because every situation is different, it is impossible to give a well-defined “if X then Y” solution to guaranteeing good performance. However, I have used the following high-level very loose rules of thumb, which don’t really help at all IMO, but sometimes seem to satisfy people.

1. More RAM never hurts.
2. Faster/more disks never hurts
3. Faster/more processors never hurts

Basically, if you want to go out and spend money on new hardware, you will not likely decrease performance. However, we can’t guarantee that it will increase performance by a specific amount either.

There is a second level of very loose rules of thumb that can be used in scenarios where people want/need guidance on where to focus their efforts/expenditures. These only apply if at least some effort has been put into identifying where bottlenecks are (or where they are likely to be). The more effort put in to understand performance characteristics, the better your chances are of making good decisions:

• If the database server I/O is heavy (ie. lots of write activity), spending more on disks is probably a good idea
• If the disk is ‘thrashing’ a lot, more RAM and more/faster disks is probably a good idea.
• If the CPU is pegged at or near 100%, more faster CPUs/cores is probably a good idea.
• If disk activity is light and CPU usage is low, network issues or blocking/deadlock issues are likely causing the performance problems. In both cases, improving application or database architecture is a good idea, and more/faster RAM/CPU/Disk will not likely help much.

1. Buzz Out Loud – CNet’s news podcast. This used to be a daily tech. news show that has recently moved to weekly. The quality of content has suffered IMO, and I am not sure how much longer I will be listening to this one.
2. HBR IdeaCast – weekly business analysis and advice podcast from Harvard Business Review.
3. IT Conversations – A wide variety of technology focused topics, as recorded from conferences, radio shows, and interviews.
4. Floss Weekly – A (usually) interesting weekly discussion of an open source project with the developers of the project. One of several TWIT network shows I like.
5. Tech News Today – TWIT network daily news podcast. This has taken over as my goto news podcast since Buzz Out Loud went downhill. Not unrelated is the fact that one of the former Buzz Out Loud Hosts is the lead host for this program.
6. This Week in Google/This Week in Tech/Windows Weekly – TWIT network weekly roundtable podcasts. I used to also listen to Security Now. But the signal to noise ratio got so bad that it drove me away (15 minutes of actual content vs. 45 minutes of off-topic random conversation)

All work and no play makes Jason a dull boy, so here are some of the less technical podcasts I listen to break up the tech. monotony.

• Brainstuff/Techstuff/Stuff you Should Know – all awesome How Stuff Works podcasts.
• Dr. Kiki’s Science Hour – Another TWIT network show, this is a weekly science podcast with a news segment followed by a detailed topic discussion with a subject matter expert.
• Quirks and Quarks – A CBC podcast on various science and technology related topics.
• Skeptoid – A weekly science podcast where the host analyzes and usually debunks popular myths and pseudoscience.
• Freakonomics Radio – a great podcast on a variety of topics that really makes one think.
• Gamespot – The Hotspot – weekly video game discussion podcast.
• No Agenda – A political commentary podcast that (in my opinion) is half serious, half satire and usually entertaining.
• Answer Bitch – an entertainment industry Q&A podcast that is usually humorous. Hey, I hear you judging! We all have our guilty pleasures, and one of mine is hearing about the vacuous lives of celebrities.
• Slice of Sci-fi – obligatory sci-fi news podcast that mostly covers entertainment industry news related to sci-fi properties, but does occasionally discuss actual science news.

1
2
3
4
5

var db = Database.OpenConnection("data source=SQL Anywhere 12 Demo;");
foreach (var customer in db.Customers.All())
{
    Console.WriteLine(customer.Surname);
}

The really cool thing about this (IMO) is there is no need to set up/design any kind of object relational mapping up front. Everything is generated for you on the fly. All the CRUD operations (create, insert, update, delete) are supported, as well as transactions and joins. This means that you do need to know the database schema up front when using these libraries (rather than using an object mapped library), and if the schema changes, you are looking at code changes and recompiles. However, since there is no mapping it is much easier to link method calls to database operations than in other ORMs, making debugging far easier (hibernate, I am looking at you).

I haven’t worked with Simple.Data a lot at this point, but what I have done has worked without any problem, and this seems like a great way to implement prototypes and small projects very quickly, especially for new developers. Also, since it doesn’t try to hide its relationship with ADO.Net through a zillion layers of misdirection abstraction, you can actually easily use an existing ADO.Net connection with Simple.Data, or get a reference to the Simple.Data connection to use with a regular ADO.Net call if you need to. You would want to do this in scenarios where you are trying to execute complex SQL, such as multi-table joins, and OLAP operations, or if you need to use dbms specific SQL, etc…

Simple.Data does not look like it is designed to replace the full-blown ORMs like entity framework, hibernate or EntitySpaces. For example, if you have complex mappings and accessors between objects and your database (eg. where an object update operation impacts multiple database tables), you will still likely want to use an ORM, and if you need access to advanced features of the RDBMS (eg. UNLOAD TABLE in SQL Anywhere), or performance is a priority, you will want to use a direct API like ADO.Net or ODBC.

The download/install for Simple.Data (and Simple.Data.SQLAnywhere) was trivial. It is available through nuget, which is how I got it. I was also new to nuget, a package manager for Visual Studio, and had no problems there either. Once nuget is installed, adding the reference to Simple.Data.SQLAnywhere was all I had to do to get everything I needed to use the library. The only hicucp I had was that my installed SQL Anywhere ADO.Net provider was older than the one used to build Simple.Data.SQLAnywhere, so I got class load errors when I ran my app. for the first time. Updating my SQL Anywhere provider fixed that problem. I was also able to download the source and project from github and build the provider myself with no problems, so if I wanted to use the older provider I could have.

Overall, I like Simple.Data so far, and I think Richard has done a good job of the SQL Anywhere support. Thanks Richard!

Another nice thing about svg is that it is also natively supported in web browsers. This means you can generate a spatial result set from SQL Anywhere that can be immediately viewed in your web browser. Here is how result set svg can be written to a file with a query:

UNLOAD SELECT ST_GEOMETRY::ST_AsSVGAggr( shape ) FROM SpatialShapes
TO 'c:\temp\shapes.svg' QUOTES OFF ESCAPES OFF;

…and here is what that svg looks like when opened in Google Chrome

The svg support in SQL Anywhere also allows you to influence the generation of the svg output by using the format parameter of the ST_AsSVG() and ST_AsSVGAggr() functions. This allows you set things like fill color, stroke width, and other details of the svg output. Combining this with some simple javascript allows you to build more interactive images, supplying dynamic labels for your image for example.
Here is an example of how you might do this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

CREATE OR REPLACE VARIABLE @header TEXT;
CREATE OR REPLACE VARIABLE @js TEXT;
CREATE OR REPLACE VARIABLE @textlabel TEXT;
CREATE OR REPLACE VARIABLE @paths TEXT;
CREATE OR REPLACE VARIABLE i INT;
CREATE OR REPLACE VARIABLE @svg TEXT;
--Set up page header
SELECT @header = '<?xml version="1.0" standalone="no"?>
	<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
	"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
	<svg viewBox="-3 -8 10 10" xmlns="http://www.w3.org/2000/svg" 
	    version="1.1" onload="init(evt)">';
 
--Create javascript functions to handle hover functionality
SELECT @js = '<script type="text/ecmascript"><![CDATA[
   var glowrate = 0;
   var target;
   var running = true;
   var varZip;
   function onhover(text) {
		running = true;
		varName = document.getElementById("varName");
		varName.firstChild.nodeValue = "Shape Name: " + text;
		target = window.event.target;
		glowrate = 0;
		offset();
   };
   function glow() {
		if (glowrate > 3) glowrate = 0;
		glowrate = glowrate + 1;
		target.setAttribute("opacity", 0.5*(Math.cos(glowrate)) + 1);
	};
function offset(evt){
	if (!running) return;	
	glow();
	window.setTimeout("offset()",100);
};
   function offhover(evt) {
		running = false;
		glowrate = 0;
		evt.target.setAttribute("opacity", "1");
   };
   ]]></script>';
 
--Generate svg document from shapes table
SELECT @textlabel = '<text id="varName" x="-3" y="-7" font-size="0.5">Shape Name: </text>';
SET i = 1;
WHILE i <= (SELECT MAX(ShapeID) FROM SpatialShapes) LOOP
    SELECT @paths = @paths || 
            ('<path fill="rgb(' || ROUND(RAND() * 255, 0) || ',' || ROUND(RAND() * 255, 0) || ',' || ROUND(RAND() * 255, 0) || ')" stroke="black" stroke-width="0.1%" d="'||
            (SELECT shape.ST_AsSVG( 'PathDataOnly=Yes' ) FROM SpatialShapes WHERE ShapeID = i)||'" onmouseover="onhover('''||
            (SELECT "Description" name FROM SpatialShapes WHERE ShapeID = i)|| ''')" onmouseout="offhover(evt)"/>');
    SET i = i + 1;
END LOOP;
 
SELECT @svg = @header || @js || @textlabel || @paths || '</svg>';
SELECT @svg;
OUTPUT TO 'C:\\test.svg'
QUOTE ''
ESCAPES OFF
FORMAT TEXT;

The result of executing the above code against the SQL Anywhere demo database is the following svg image (hover over the various shapes to see the description change):
Update: Apparently Chrome doesn’t like object or embed tags, so I changed to iFrame. The image displays small in IE for some reason I haven’t looked into yet, but still functions correctly.

An example of this is the SQL Anywhere Server Monitor (available with the SQL Anywhere Developer Edition) which allows you to monitor the health and status of your SQL Anywhere and MobiLink database servers. The server monitor application is flashed based and resides inside a SQL Anywhere database. When you run the monitor application, it starts runs a local database server with the http option turned enabled and loads the server monitor database file, which makes a set of web services available. To access and use the monitor from any machine on your network, all you do is point your browser at the server.

1. Improving service/support
   I talked about this point when discussing how ISV’s can reduce costs by moving to the cloud. It follows from this discussion that if you have control over the deployment environment you have a smaller testing matrix, less variability in deployment environments and can more easily push out updates. These things lead to a more consistent experience for your customers, making them less likely to run into unforeseen problems with your application service, and creating a better experience for them. SQL Anywhere OnDemand helps to ease the support and manageability of a large multi-tenant environment by allowing you to view and manage your data cloud from a central web console, where you can generate proactive alerts, collect diagnostics and deploy tasks to customer databases to help you resolve issues.
2. Application Customization
   We’ve all had customers who make what we feel are unreasonable demands of our products. Whether its using the product outside the realm of its intended use (or even its imagined use in many cases), or simply hitting the limits of the product in their specific environment, every customer has their own unique requirements.
   While it would often be beneficial to address at least some of these demands, it is not possible to satisfy every customers wish with a packaged application. An ISV cannot usually afford to make customizations to suit a particular installation, and the customer cannot afford to pay for the services and support required to make application customization.
   With an appropriately configured SaaS environment, you can offer these extra levels of service to your customers, at a more affordable cost to them. For example, by supporting complete tenant isolation, SQL Anywhere OnDemand allows you to make database schema changes for individual customers. Things like creating custom reports or adding an additional column to a table, are trivial to implement with no impact on other users of your service. In addition, you can easily compare tenant databases in your cloud to other tenant databases, or to a reference schema to identify any differences.
   Many customers may not take you up on the customization options, but your ability to do this will differentiate you from competitors and improve the satisfaction of your most demanding customers.
3. Providing Additional Services
   How many times have you had a customer call your support staff stating their machine crashed and they don’t have a backup? I can tell you that when I worked in technical support, this was not an uncommon occurrence. No matter how often we drive home the importance of backups (especially for the database), end-user customers don’t realize their importance until that inevitable fire/flood/hardware failure occurs. The worst part is (at least for the ISV) that regardless of the actual cause of the failure, it is the ISV who usually takes the blame.
   Providing backup and HA services for your customers is a requirement for any SaaS solution you offer, and doing this will make your customers happy (perhaps blissfully ignorant would be a better term…). With SQL Anywhere OnDemand, providing high availability and managing tenant backups in your data cloud is easily managed with the web console. Ideally your end customer will never even know that you had to failover to another node in your cloud, or that you had to recover a database.

This list is clearly not exhaustive, but gives an idea for the types of things that a SaaS solution can bring to the table in terms of improving customer relationships, and how SQL Anywhere OnDemand Edition can help ISV’s get there. Of course, getting there is the key, and we will talk about some the hurdles of moving to a SaaS environment in future posts.

]]> http://iablog.sybase.com/hinsperg/2011/12/isvs-can-improve-customer-satisfaction-by-moving-to-the-cloud/feed/ 0 http://iablog.sybase.com/hinsperg/2011/11/isvs-can-reduce-costs-by-moving-to-the-cloud/ http://iablog.sybase.com/hinsperg/2011/11/isvs-can-reduce-costs-by-moving-to-the-cloud/#comments Fri, 11 Nov 2011 18:08:50 +0000 Jason Hinsperger, Product Manager http://iablog.sybase.com/hinsperg/?p=513 For a change of pace, and to try something new, I decided to try my hand at writing a less technical post. Here goes nothin…
SQL Anywhere OnDemand Edition (codenamed “Fuji”, currently in beta) is designed to enable ISVs to take business applications to the cloud without compromising the functionality or quality of their products and services. However, as an ISV who has traditionally sold a packaged software solution to your customers, why would you want to move to the cloud at all?

One reason is that moving to the cloud (if done right) offers some ways to reduce costs. It may also increase costs in other areas (eg. infrastructure), but we will cover that in another post. A few reasons come to mind on how costs can be reduced:
1. Reducing development costs:
   When building packaged software, you need to support and test a variety of end user environments. How many of these you support depends on how much of your target market you want to capture. However, each supported platform combination (OS, HW, etc…) requires additional development and testing resources, adding to your overall costs. SQL Anywhere has definitely encountered this issue. Take a look at our Supported Platforms Matrix and imagine the testing matrix we have for each release. To complicate things further, new versions of the software support databases created with older versions of the software (eg. you can run a database created with SQL Anywhere version 10 on a SQL Anywhere version 12 server), further complicating the testing matrix.

   Because the cloud can offer you a known, consistent platform for your software to run on, and allows you to decide when and how upgrades occur, you can significantly reduce development and testing costs by offering your software as a service.

2. Reducing deployment costs
   Every customer has their own unique production environment – from the machine in the back room to the full service IT department with racks of servers. All hardware is not created equally. The cheaper the components of the hardware, the more likely there are going to be issues with it. Again, looking at SQL Anywhere as an example, we have no control of the deployment environment our customers and OEM’s deploy to, aside from our documented minimum requirements. We have run into cases where different versions of hardware drivers at various levels (eg. hard disk drivers) had bugs, or deliberate behaviour (like ignoring flush requests) which caused database corruption to occur. Fortunately these issues are relatively rare and we have developed some methods for dealing with them, but these are only issues that would occur upon deployment.

   On top of the hard to track down hardware issues, is the much worse issue of what software is running on your customers’ computers. From virus to antivirus and MS Office to WoW, all the software on a machine contributes to making every customer deployment a unique adventure.

   It is impossible to test every nuance of the varied deployment environments for your software, so you do your best to ensure your software will work in the majority of cases, and rely on your deployment and support teams for the rest.

   With the cloud, because you control the deployment environment, you can actually test and verify ahead of time, and be much more confident, allowing you to reduce QA and deployment expenses related to production installs of your software.

3. Reducing support costs
   Related to the deployment environment is ongoing support for your application. You have no control over your end user environment. I have answered many support calls where a user says “I never did anything. Your software just stopped working.”, only to later find out some other piece of software like the OS or antivirus installed an update behind the scenes, breaking the application.

   This sort of thing should not happen in the cloud. Your customers can have a much more consistent experience with your application because you control the runtime environment. Nothing changes in your hosted applications runtime environment until you test and approve it.

While the above things can have a direct impact on your costs, they can also have an indirect impact on your business. Two examples that come to mind immediately are:

1. Fewer install and support issues means happier customers, and happy customers are loyal customers.
2. Less time spent on debugging and support issues means more time for your engineering teams to focus on new innovations to make your product better.

While cost reduction is only one benefit of moving to the cloud, it can be a significant motivator for both you and your customers. SQL Anywhere OnDemand Editiion can help you get there by enabling you to build and manage your own data cloud platform service on top of which you can build your SaaS applications.

]]> http://iablog.sybase.com/hinsperg/2011/11/isvs-can-reduce-costs-by-moving-to-the-cloud/feed/ 3 http://iablog.sybase.com/hinsperg/2011/03/create-a-heat-map-with-sql-anywhere-and-sap-crystal-reports/ http://iablog.sybase.com/hinsperg/2011/03/create-a-heat-map-with-sql-anywhere-and-sap-crystal-reports/#comments Wed, 02 Mar 2011 15:19:07 +0000 Jason Hinsperger, Product Manager http://iablog.sybase.com/hinsperg/?p=471 There is a whole world of possibility available for visualizing your data spatially.
SAP Crystal Reports is a tool that helps you to create reports to visualize your data. Along with an intern, I was playing with it (or maybe ‘evaluating it to understand its capabilities with regards to SQL Anywhere’ would be a better way to phrase it…), and found that one of the things you can do is create ‘Heat Maps’, which is a simple way to visualize your data on a map without having to learn about or use spatial data in the database. Using Crystal Reports 2008 and SQL Anywhere 12, we were able to create a simple heat map report easily and quickly, allowing me to visualize the density of customers in the SQL Anywhere demo database across the US.
However, this was just the tip of the iceberg. You can move on from there to leverage spatial support in SQL Anywhere to create a variety of reports that help you to slice and dice your data in many different ways.

To plot the location density of customers on a USA map we first created some ranges, so that each geographic area (state) could be colour coded according to the number of customers in that state. That allows us to very quickly identify those states where we have a large presence, which can impact where we might plan roadshows and customer visits. It also shows us where we have relatively few customers, which may indicate untapped market opportunities.
You can imagine how you could use other metrics (like revenue) to derive similar kinds of insight from your data.

Using the Database Expert from the Standard Toolbar, I can open ODBC “SQL Anywhere 12 Demo” data source and see all of the tables in the database. Even though we aren’t actually using any spatial capabilities of SQL Anywhere, I used the SpatialContacts table because it has findable addresses in it.



Next I opened the map expert from the Standard Toolbar (Insert->Map)


I switched to the advanced layout and dragged the “State” column from the SpatialContacts table, into all three of the provided report fields (Geographic field, On Change of, and Map Values).
Then I selected “Ranged Map” from the Map Expert tab.

My report was now ready to preview (view->preview from the standard toolbar). Click for a larger image


Thats basically all there is to it. You can edit or modify the graph by right-clicking on it in the Preview tab; change the map or change the visible layers on the map (note that some layers like Ocean may cover other layers, preventing you from seeing your data).

]]> http://iablog.sybase.com/hinsperg/2011/03/create-a-heat-map-with-sql-anywhere-and-sap-crystal-reports/feed/ 2