Hi, good afternoon. My name is Matt Sturgis. I'm one of the alliance managers in our worldwide developer relations group. And I'm here today to introduce to you Sybase and some of their great partners and customers to talk a little about session 621, Sybase ASE and the replication server. A new product recently released in April that we're very excited about for the Mac community.

For those of you who know or don't know, Sybase has actually been on our platform for a couple of years now and has had a very successful run with Mac OS X and specifically with the XServe. It has some really great named customers and partners on their platform. So we're very excited to have them up here with us today.

And like I said, Steve Olson, Director of Development or Director of Engineering from Sybase is going to come up and speak to you for a little bit and then introduce some of his great partners. And a customer, actually Apple, as one of our proof points about how great the technology is and how excited we are to be working with Sybase. So with that, I'd like to introduce Steve and... Thanks, Matt.

Okay, thanks Matt, and thank all of you for coming today. I appreciate your time. I realize I'm standing between you and your evening plans, so hopefully this will be worthwhile. And I also want to thank Matt and our friends at Apple for giving us this opportunity to talk about what has become our favorite subject lately, which is Sybase on OS X. So what I'm going to talk about is... We're going to talk about Adaptive Server Enterprise, which is our enterprise class database that we've had since the early days of Sybase, and the replication server 12.6.

I'll explain a little bit about what replication is and then talk about the product itself. We'll talk a bit about the optimization we've done for G5, some of the performance results, and we'll also talk about some compatibility with Microsoft SQL Server and the effort it might take you to move from SQL Server to ASE. And then later, towards the end, I'll introduce various partners and customers that have had successful deployments of applications using our server on OS X.

Available today is the latest release of ASE called 12.5.2 Replication Server 12.6. This is new, just released in April of this year, late April. We also have a number of client interfaces available for the Mac, JDBC, ODBC, our own proprietary APIs called Open Client for you to build C or C++ applications using our native APIs.

And also we have a mobile and embedded database that has been very successful in its market niche called Adaptive Server Enterprise, sorry, Adaptive Server Anywhere or SQL Anywhere Studio. Version 9.0 is the latest release and that's available on OS X as well. We love the Mac OS X operating system and we are committed to continuing our support and enhancing our support on this platform over time.

Focusing on ASE, again I mentioned that Sybase was founded in 1984. Our first public release was in 1987, version 2.1. It was licensed to Microsoft about a year later and we did a port to OS 2. And we then established a business relationship with Microsoft that lasted approximately 10 years. So we have a lot in common even today after all of this time. There's still a lot of commonality between the SQL Server of Microsoft and ASC. We basically implement a standard SQL language, SQL 92, plus a number of extensions specific to the OLTP environment.

Architecturally, we rely heavily on the Unix services provided by any given platform. We also are available on the Windows platform, but we're highly optimized for Unix. Back in 1984, when the company was founded, the first platforms that we considered moving our software to was VaxVMS and SunOS. And if you recall back in those days, SunOS was essentially the first commercial implementation of Berkeley Unix.

So BSD Unix is very familiar to us, and we're very happy to see it again in a commercial product. It's an old friend in a new coat. So we rely heavily on it. And essentially what ASE is about is it's a Unix process. We call it an engine. And we build our own threads. We manage our own threads. And each engine manages some number of threads. And its own scheduling and so forth.

Engine zero reads a config block and determines how to allocate memory. And then initializes a shared memory region that is used in case there's additional engines. If you have two CPUs, for example, you can attach or configure a second engine. If you have ten CPUs, you could configure ten engines.

So engine zero is very similar. So engine zero creates the shared memory region, and all subsequent engines then attach to it. And the shared memory region contains our data cache, our procedure cache for stored procedures, for compiling ad hoc queries. And it also contains all of the system metadata, information about objects, our scheduler queues, thread-specific data, and so forth. All of that is resident within shared memory. So we're very, very happy this week to learn about the 64-bit capabilities of TAS. Because with a 32-bit application, you are limited to about a 4-gigabyte address space.

With 64 bits, what it means to us is the shared memory region could be essentially as large as you can configure memory on a machine. So 8 gig, no problem. Recently, we've done a benchmark with a major hardware manufacturer involving 256 gigabytes of memory. So if Apple provided us with a machine that could configure or contain 256 gig of memory, we would be able to use it. And the advantage there is that the more data we can put in cache, the less I/O we have to do, and therefore the better the throughput is going to be, as a general rule.

So engine zero listens for connections and then determines the load that's on all of the engines and dispatches to the engine with the fewest number of connections. So we do some load balancing there. Each engine communicates with clients then through Berkeley sockets. And each engine is capable of handling about 3,000 or up to about 3,000 connections. For a total on an XSERV today of about 6,000 client connections. Okay.

So we've also added some extensions to this port to take advantage of some unique facilities offered by Mac OS X, including Rendezvous. When our server comes up, we register with Rendezvous so that any Rendezvous-enabled client can detect the presence of this server in the network. It's a very simple interface, but a very powerful capability is enabled through this interface. So during initialization, our server comes up, figures out its port number, etc., and then registers with Rendezvous and makes its presence known to the network.

We also provide a Cocoa-based application, which is essentially a discovery tool that lists all of the servers in your subnet, all of them available through Rendezvous. It's a Rendezvous client, listens for connections of a particular type or for services of a particular type, and also has a login panel.

So as you scroll through this list of services or servers, the information that is needed to enable our client APIs to connect to that server is showing up in the login panel. The host name, the port number, you provide a login name and a password, and then we pop up an interactive SQL query window.

So you can then issue queries, the results are displayed in the middle panel, and then errors and messages and so forth. And then the results are displayed in the middle panel, and then errors and messages and so forth. So this is an interactive SQL application that requires no configuration whatsoever on your part. It's just all enabled through Rendezvous, which is a very powerful capability.

Open Directory Authentication. ASE has recently implemented a feature we call Directory Services Authentication. And what that means is in past incarnations of our server, all of the user information was stored in our system catalogs. The login name and encrypted password and so forth. And so you had to manage the passwords inside ASE. You have to manage the passwords in your operating system and perhaps elsewhere.

What Open Directory Authentication does is allow you to authenticate a login using the passwords that might be in an LDAP server, Active Directory, maybe Kerberos, or even Network Information Services or the Yellow Pages, depending on where you prefer to store user information. So we can authenticate based on information that's common to all of your services and all of your platforms. So this is a very popular feature. On other platforms, we don't use Open Directory. We use PAM or Plugable Authentication Modules. And on Windows, we use Active Directory.

With the Panther release of OS X, a very interesting feature was added to the release on the OS X server, which is called Server Admin. Server Admin allows you to specify a number of hosts that are available in your network and lets you manage and evaluate and get a status of all of the services on all of those hosts.

So in this example, we have four servers that are configured inside the Server Admin tool, and one of them has a pull-down showing all of the services available on that machine. So what we have done is provided a plug-in on both this client and on the server side for Adaptive Server Enterprise to allow you to manage ASE through the Server Admin tool. And in this shot, what comes up is simply an overview. It tells you the status of ASE and the backup server that are running on this particular host.

We also provide a graphical interface that shows you some of the characteristics. We have, in this example, network I/O, the amount of network I/O in terms of reads and writes. We also provide a response time graphic. We provide a graphic for disk I/O and also for procedure and data cache hit ratios.

In other words, one measure of the configuration accuracy or optimization of your server is whether or not your data cache is optimal for the load. And if most of your data access is basically logical reads or logical writes, that means you're not doing physical I/O to disk. So the ratios should be fairly high. And we show a graphic showing you the ratios of the logical to physical reads reads in both the data cache and in the procedure cache.

So it's a very powerful tool and it gives you an ability to get a status report at a glance indicating the general health of your server. We also provide some tabular reports that give you some idea of the operational characteristics, number of users, number of engines, and so forth. There's a lot of information you can get a quick read of the health of your server through this tool.

We also provide for development purposes a system preference panel. So you can go to system preferences after you've installed our server and pull up a Sybase ASE preference panel. And that will tell you what's going on with the server, whether it's up or not. It's a rendezvous client.

Those green dots indicate that a server is up. And if they're red, that means there's a problem. And if they're not any color, that means the server is down. You can look at the error log for the server, and you can also configure it or revise the configuration of the server.

So what's new in 12.5 too is we've done some optimization specific to the G5 processor, and I'll talk more about that in a bit. We also provide a sample application. It's an Xcode project that illustrates the use of Rendezvous, Cocoa, and Open Client. It's based on the server discovery query tool that I showed you earlier, and we provide a sample application that illustrates how all these things, Cocoa, Rendezvous, and Open Client, can be used together in an application. We also provide our Open Client APIs in a Mac OS X framework so that you can embed the framework in an application bundle or to make it very, very easy for you to deploy applications throughout various clients.

Also, we found through the use of Shark, which is an outstanding tool for getting a quick profile of what's going on with your application, we found that some of the system functions in the C runtime library were kind of holding us back. And so we re-implemented or implemented some of those of our own so that we could get past those bottlenecks.

So we're not where we want to be yet. There's a few things that we can do with the compiler, including feedback optimization. Feedback optimization simply means that you compile with certain command line options and then run the product or your application under a representative load. And then the feedback-optimized server will collect information about the use of routines and some statistics about the running of the server. And then you can relink feeding that statistic file into your linking process to basically give you a more optimal layout of your executable. And that's something we've done very, very successfully. And it usually gives us a 15 to 20%. Boost in throughput on our TPCC tests.

We have looked at the PowerPC compiler from IBM, and it's very interesting. It has some additional optimization features over GCC, but GCC now has the ability to give us 64-bit processes. So we're not so sure where we're going to go with the PowerPC compiler from IBM. But anyway, our expectations are, based on the horsepower that we've seen and the throughput we've seen from the G5s, we should be able to get about 30,000 transactions per minute per CPU from the G5s for a total of at least 60,000 transactions a minute on a dual system. Now, that's not too bad.

That's about what we've seen on other platforms. But the interesting attribute of this test that we learned was that we are completely... 100% CPU bound, meaning that we're not waiting on I/O from the network, I/O from the disk system. We're completely CPU bound, which means that if Apple, for example, had a 3 GHz CPU, we should see a proportional increase, a 50% increase in throughput. From the testing we've done, the X-rayed units are more than capable of handling the kinds of load that we've been throwing at it. In fact, I don't see us... I mean, it would take more horsepower before we started to see the I/O system being a limit.

Okay, so one of the attributes that we found to be important to our customers is our SQL server compatibility. We're finding increasingly that customers are somewhat unhappy with Microsoft for a variety of reasons. There's an interest in Unix-based servers as opposed to Windows-based servers. And there's an interest in moving from those servers to ASC. And because of our common heritage, that's relatively easy. So as I mentioned, the server from Microsoft was licensed from Sybase, and we have a lot in common still. Even though late in about 1998 or 97, the two companies parted ways, we still have a lot in common.

So there's a high degree of compatibility. There are, however, some incompatibilities because we have evolved our product in a certain direction and Microsoft has evolved its product in another. But there's a high degree of compatibility still between the two. So what we've done is we've adopted a strategy to minimize or reduce the incompatibilities over time. It's not going to happen all at once.

For example, with 12.5.03, we introduced a number of new built-in functions and some global variables to enhance the compatibility of our server with Microsoft. With 12.5.1, we've added some additional syntax to our language, specifically for purposes of compatibility with SQL Server. Derived tables, bracketed identifiers, sort of a unique SQL Server construct that allows you to create an identifier.

For example, a table name. Or a column name with spaces or maybe it's a reserved SQL keyword. Very easy to use that as a column name or table name simply by surrounding it with brackets. And so on. So we've added a number of constructs within the language for this purpose. Next year, we'll have a new release, version 15, where we'll address some additional more significant issues. For example, large identifiers. Identifier lengths today are 3.5. Identifier lengths today are 30 bytes.

With SQL Server, it's 128 characters. So we're adding up to a 255-byte identifier support, scrollable cursors, forward, backward, relative, absolute, and so forth. Additional data types that are found in SQL Server today but not in ASE. Computed columns, columns whose value is determined by values in other columns. And the select top. So one of the examples I'd like to talk about briefly is our partnership with SAP Business One.

They've moved their application to ASE. And some of the issues that they encountered in the process of doing that, I'd like to just review fairly quickly. They ran into some data type issues. In particular, ntext. ntext is a Unicode text data type. And there's no equivalent in Sybase. However.

We can configure -- they ended up using text as a data type with a default character set of UTF-8, which gave them equivalent capabilities. Select top was used extensively by Business One. And we had -- we did not support that syntax. So it was painful for them to work around that issue. They used Active Directory for user authentication. And that wasn't available, at least at the time. It is now. ODBc Driver Performance.

We have a partnership with a third party to provide ODBc drivers. We had some performance issues, so as a result of this issue, we decided to just roll our own ODBc driver. And that's what's happening now for Windows, Linux, and OS X. That driver is available now in beta on Mac OS X if you're interested. So they also ran into some query limits and server limits.

They're just different on ASE, and we had to address those. And also some administrative tasks that were different between the two servers. And most of the issues had to do with administrative tasks. Our administration tasks are different. The syntax is different. The behavior is different. And so on.

So those are some of the issues that Business One had to address. And the interesting thing, though, is that we now have a partner team in engineering focused specifically on addressing issues related to porting an application or moving it from another database vendor to ASE. And if you have an application that is interested in doing that, we'd be happy to help you out, as we've done with SAP and Business One. Tools of course make it easy. We can migrate schema and data from just about any server to ASC. And later you'll hear from Bob how Servoy can make this happen as well.

Once you've moved the server, the data and the schema, you also have to concern yourself with the client. We provide ODBC drivers, OlayDB on Windows, ADO.net on Windows, JDBC on any platform. It's a pure or type 4 driver. And Visual Basic. If your application is in Visual Basic, you can use Real Basic.

We provide a plug-in for the Real Basic software that uses ASC. And of course, DB Library. One of the things that besides the server, Microsoft also inherited DB Library. And they again have evolved their API into in a different direction slightly. So there's a lot of commonality, but there are some differences, especially in terms of data types.

So our goal is to make it as easy as possible for you to migrate from SQL Server to ASC. And we're doing that by enhancing our server to be as compatible as possible. Now it's a moving target. I expect that the UConn release of SQL Server will have additional syntax, but we're keeping track of that. And as issues come up that are raised by you and our partners, we expect to address them within our server.

I'd also like to mention some other tools and solutions available today using the Mac, ASE, and OS X. The WebObjects product has an adapter for it that is designed by Apple and supports ASE. It's on the CD when you buy WebObjects. Real Basic I've already mentioned. Another one I'd like to point out is an outstanding product. If you want to build a Cocoa application using a very slick user interface, using, you know, advanced objects for database session and result set management and so forth, take a look at Runtime's labs. It's all written in C, C++, Objective-C. It's a dynamite tool and framework.

Also, you'll be hearing more later in this session from Servoy, who has a very, very nice tool for Java implementations, and Bob will be talking about that later. PowerEasy is an interesting solution. They have an ERP application for small to medium-sized businesses. It's an outstanding package, and it's a complete solution.

And so forth. So, replication server. I'd like to talk briefly about this. What do we mean by replication? Replication is essentially copying database changes from one server to another. And when we say copying database changes, we don't mean any changes. We mean on a transaction basis so that all of the changes associated with one committed transaction can be propagated atomically to another server. So, if the transaction is rolled back in the middle, changes that might have occurred are not propagated.

It's a store-and-forward model. We have a replication server which captures changes from our transaction log.

Models that our customers have used tend to fall into four categories. There's a model of data distribution where you can distribute data from one site to n number of other sites. Consolidation, meaning any number of sites can replicate their changes to one central site. Synchronization is essentially a bidirectional replication.

And then disaster recovery or what we might call a warm standby where you can replicate all the changes in a database to a warm standby server so that if your site is suddenly taken out, you have a backup or a warm standby. And we'll talk more about that.

The distribution model is relatively straightforward conceptually. You have changes going on at a central site, in this example San Francisco, that need to be propagated to any of a number of other sites, including New York, Dallas, or another San Francisco installation. So that's the data distribution model. And again, it's a publish/subscribe. All of these three servers have to subscribe to those changes, and the ASE then has to publish those changes. So there is some setup. We have tools for that, making it relatively easy to do that.

Data consolidation is very similar, except it's just going the other way. Changes from any remote site can be propagated and consolidated into a single central site. Synchronization is basically a bidirectional replication, nothing more complicated than that. If there's conflicts, in other words, keys are duplicated in either direction, then they're placed in a rep server queue and you have to resolve them manually.

And then there's the warm standby or disaster recovery scenario. So you have some number of clients interacting and transacting with a primary server. Changes are replicated en masse. In other words, the entire database is replicated to a standby server. The changes are placed in a queue and forwarded when possible. Now, the primary may crash or, you know, you may have a power outage. Something may happen on your primary server.

Our client APIs allow automatic client failover to an alternate server. And our replication server can be notified to reverse the direction of replication. So when this happens, the queues from the primary to the standby are drained. And then all the changes in the standby then... are propagated back to the rep server who places them in a queue until the primary becomes available.

And a lot of our customers use this. For example, we had a number of customers in the World Trade Center on 9/11. Their entire site was taken out. And fortunately, some of them had backup sites in either Chicago or London or... There were no geographic... There are no geographic limitations on where you can... where you can put your standby. It's entirely up to your network and how much bandwidth you want to pay for in a wide area network. So they were able to recover and get back online very, very quickly.

Architecturally, the model is fairly simple. A server that wishes to publish changes has to have a replication agent. Within ASE, that agent is simply a background thread, one for each database that reads the transaction log and then forwards changes to the replication server. The replication server then knows who the subscribers are and then propagates those changes to subscribers.

The agents we provide are, of course, agents for our own Sybase servers, but we also provide agents for Oracle, DB2, Microsoft, Informix, and AS400. So these are log-based agents that read transaction log, mostly log-based agents, read the transaction log, forward data to replication server, who then treats it like it came from ASE and propagates to any subscriber. And the subscriber need not be a Sybase server. It can be any server. It can be Oracle.

It can be DB2 or Microsoft and so forth. So one example of topologies that some of our customers have employed, some of our largest customers, for example, Goldman Sachs, which is one of our largest users of RepServer, have sites all over the world. And they have consolidation, distribution, synchronization issues, as well as warm standby issues.

So they have some fairly complex topologies, and all of those are supported very nicely by RepServer. With version 12.6, which was announced just in April, available now on 10.3 of OS X, we now support multi-site availability. So you can essentially establish channels. One RepServer might propagate to other subscribers, which are ASEs, but you might also forward to another RepServer.

In other words, a RepServer might be a subscriber, and it can forward changes to other ASEs. So you can fan out the changes. And obtain near infinite scalability in this fashion. We've also simplified the interface. It's a graphical tool built on Java, so that's also available and running well on the Mac. And the installation uses InstallShield.

So, it's available today and it's designed primarily for downtime, to manage downtime and to distribute data. I would say more than half of our customers use RepServer for managing downtime, either planned or unplanned. And, of course, many use it for distributing data around a network, but the majority now are using it for managing downtime. By providing, you know, standby servers. Okay, and now I'd like to introduce Eric Leister who's going to talk about an implementation at the Apple manufacturing facilities and he has an interesting application using WebObjects.

So what I'm going to start with first is sort of what our business challenge was, what we were trying to accomplish. Basically, Apple needed an enterprise system that would basically allow us to report and consolidate product performance information, basically yield information from the factories, and be able to provide that data and the status of how things are running from multiple sites at the same time.

Before, that was being done with emails and with spreadsheets and things like that, so you can imagine it would take a long time to consolidate that information together. It also needed to provide data that was accurate, real-time, and actionable. Again, being able to look at the data and do something with it rather than consolidate data, so we were trying to put all this stuff together. Provide real-time data for analysis during our engineering builds, which would be for new products, to quicker get data rather than having to wait a day to get data, it would be there immediately. Again, coming back to high availability.

We wanted to make sure that we were able to get the data that we needed, and then also more effectively manage these new builds, so that, you know, bring products to market quicker. The capability also needed to be there to integrate with our test environment, so we actually captured detailed test information about the units that are being built, so that we can more quickly root cause issues.

So we had a set of database requirements that we wanted to have in the database. So one was support a mission-critical system, be able to handle high transactions. We have lots of volumes going through the factory, so we need to make sure that it can handle those volumes.

High performance and be very scalable. So as the factories create more product, we need to be able to handle that volume. Also be able to have a warm standby. So if something goes down, hardware issue, drives, we'll be able to cut over to a backup system. Also have a WebObjects adapter and run on OS X.

Application requirements. We wanted something that was database independent. So basically whatever development we did there could be run basically with any type of database. Provide rapid development tools. Basically we're being asked to customize reports, add new fields, things like that all the time. So we need to make sure that we can go in and quickly do that.

Easily maintainable deployment. Basically being able to deploy the applications quickly. The fact that we can put them on the web means we can update them quickly as well. They need to be scalable. If we need to add more instances or more servers, we need to be able to deploy those quickly. And also run an OS X server.

So from an architecture, we basically put all this on one server for our deployment to the remote site. So we start with Mac OS X Server. We add Sybase ASE. Then we put the WebObjects layer on top of that. Our own data frameworks or data collection frameworks go there. That's where all our business logic, reusable components, things are at.

Then we have daemons and reporting admin and shop floor client applications for collecting data directly on the lines. Again, all this is running on one server. So our server hardware configuration consists of, we're running G4 dual processor 133s with 2 gigs of RAM, OS X Server 1033, Sybase ASE 12.5.1, WebObjects 5.2.3, and Apache with just the standard WebObjects deployment through Java Monitor.

So our server hardware configuration consists of, we're running G4 dual processor 133s with 2 gigs of RAM, OS X Server 1033, Sybase ASE 12.5.1, WebObjects 5.2.3, and Apache with just the standard WebObjects deployment through Java Monitor. We're running G4 dual processor 133s with 2 gigs of RAM, OS X Server 1033, Sybase ASE 12.5.1, WebObjects 5.2.3, and Apache with just the standard WebObjects deployment through Java Monitor.

So our database schema, we have about 95 tables. One table has slightly over 9 million records and is continually growing every day. We have five tables with 1 to 5 million records each and 10 tables with over 100,000 records each. Everything, all the other tables are less than 100,000 records.

We also use Warm Standby, basically replication server with Warm Standby for our primary and secondary databases. And we use table replication to the remote sites, which we go through here next. So basically, we have three ways that we migrate data between the databases. We have Warm Standby that replicates between the primary and the secondary database. We happen to also use the secondary database as a reporting database. That's one of the main reasons we've broken out the applications between reporting.

We have the reporting apps, clients, and admin apps so that we can have the reporting apps actually target our backup database. So it's not actually the transactions or big selects for like a year's worth of data do not affect inserts and updates into the other database, the primary.

We also have table replication for about 31 tables that pump things like usernames, passwords, other information that needs to be shared across the sites. Those are all going through table replication. And then we have an export-import routine that we use. Basically, we use the EO model, and we dump the data into flat files, and those get FTPed back and forth between the sites just to keep the data warehouse in sync.

So we decided to do some performance testing to see just how, when we were trying to evaluate databases, what kind of performance we could get. So what we did was we started with a dual G4, 1 gigahertz with a gig of RAM. We had a RAID box with RAID 5 and OS X Server 10.3.3 and 12.5.1 of Sybase. And what we did was we simulated 10 lines in a factory running as fast as they can.

To sort of put that in perspective, you can imagine that a line, the way we measure the performance of a line is by cycle time. So if you have a 30-second cycle time on a line, that basically gives you two units or two widgets off of a line per minute.

So with 10 lines, you'd have 20 units a minute coming off all 10 lines. And what we were able to do in our simulation was generate 1,800 unique serial numbers per minute, which is basically almost 20 times. So that's about a hundred times more than what the 10 lines would normally do under a 30-second cycle time.

So if we take that transaction load, we use SP Sysmon, which is a stored procedure to give you sort of transactional information. We found that we were getting about 466 transactions per second or 28,000 transactions per minute or 1.68 million transactions per hour. And of those, they're the percentages, 70% of those are inserts.

So there's actually a lot of I/O going on there. 15% updates, 8% selects, and 7% deletes. After we did some more research, we found that actually the 8% selects is actually much lower than what the number of selects are truly going on there. The 8% selects were more of updates that basically end up being selects and not actually updating records in the database.

So we figure that it's probably closer to 2 million transactions if you counted selects, if we were able to get that in there. And then also we have the two engines going. So we were about 75% utilizing CPUs. So we think if we added another XSERV that was running our simulations, we could actually get even more performance out of the system.

So now I'm going to sort of go through a demo of the web application that we put together that'll show how we report the information. It's just one of the many pieces of this whole system. And it's all sort of simulated data, so it's not real data in there. But this is sort of the login screen. We do user authentication through the system as well, so we can go in, username, password.

The first screen you come into, it gives basically management the ability to go in, choose what sites they're interested in, and then see what products were actually built at that site. So you can imagine these would be, they're just generic names here. But as you can see, you can see what the current calendar week's yields are, what the previous weeks were, so you can see if there are any trends going on. And in this case, you can see there's 66% last week versus this week, which was 80%, so we could drill into that and see what's going on.

Then we see that there are the two sites that we're looking at, and you can see there's 64% QM yield for site two and 72% for site six. So we can then drill into site two, and then we actually have a graphing that shows what the volumes were for that week, how the trending yields are going, what the yield points, these are just generic yield points here. So you can see what's going on, top five failures.

If you scroll further down into the graph, you'll actually see more detailed information, what happened on each day individually. And then again, you can root cause down to see, okay, there's a spike down there at 8% on the ninth. We go into that, and then we can actually see the list of serial numbers, what the failures were, rework actions.

Again, this is just sort of touching the surface. You could drill down further into the serial number and see details about the failures, how many times it had been through certain tests and all that. So that's it. Okay, I'd like to introduce Dr. Keith Campbell from Oveon, who will be talking about his application and what he's doing with some very interesting technology. Thank you. I wanted to start by just trying to motivate why Inovion is trying to do what we're trying to do.

What do you want when you lose your sight? Prevent diabetic blindness. Diabetic blindness is the number one cause of preventable blindness in the United States today. And the sad part of it is that 90% of the patients that go blind, it could have been prevented if they had treatment in time. And diabetes is a growing problem in the country. There's more and more people being diagnosed with diabetes all the time. They're talking about, you know, the epidemic of obesity and of diabetes subsequently in our population.

And even though there's treatment that's 90% effective, only 40% of patients actually get that treatment done, excuse me, that test done every year. And that's really a tragedy because a lot of people are going blind. So this is the problem we're trying to solve. And Inovian is trying to solve this through technology.

So, for our diabetic retinopathy evaluations, What does Sybase provide us? Well, one of the things is that when we were looking at re-architecting, OS X had come out, and one of the questions was raised was, well, can we use the same platform end-to-end? And at the time, we had very limited options, and actually when we heard the announcement that Sybase was going to come out on OS X, that really changed the way we started thinking about the infrastructure which we would deploy it, because we were able to have an enterprise class database that would provide the reliability that we needed and allow us to focus on some of the other issues of reliability in the computing out in the edge. So it's something that has basically allowed us to work on our business enterprise architecture without having to worry about the database, which was one of the things that we had had to worry about in the past.

So, excuse me, Sybase provides us with these warm copies of data so that we can have quick deployment. We have a lot of data storage, we have a lot of data storage management, we have a lot of data storage management of standby, reporting copies and backup copies for disaster recovery.

We use a hierarchical storage management system for storing these 50 megabyte digital files, and we have pointers from the database to the hierarchical storage management system for doing that. What Sybase provides us, again, is this enterprise class scalability and reliability, support for redundant data centers, confidence in the data integrity and reliability, and also in a very cost-effective and yet proven reliable solution.

And finally, I'd like to introduce Bob Cusick from Servoy. He's the managing director of Servoy USA. We'll talk about the Servoy R2 deployment. Thank you, you guys are brave. The last presenter of the last session. Woo-hoo! Okay, I have about 200 slides. No, I have three slides and then a real demo. All right, so hang in there. We're almost there. All right, I'm going to talk about Servoi R2.

Servoi R2 is a development and deployment environment for GUI applications that can be connected to any SQL database that you want, or more than one simultaneously. And we can actually see it. So this slide is kind of mute. It's very easy to use. Zero deployment client. It's based on Java, so it will run anywhere, and you'll see it.

I just wanted to talk to you about some of the things that you can do with Savoy. And in particular, I wanted to talk to you about a really big win that we got with Stanford using Sybase ASE and Sybase ASA as well as Savoy. So here was the challenge. We had to integrate a whole bunch of stuff and they have legacy things inside of the university that you wouldn't believe. Everybody has their own favorite database.

It could be Informix, it could be Sybase, it could be ASA, it could be Oracle, it could be anything. And they needed to put it all together. So the way that they were doing it is they had knowledge workers who would get data dumps and exports and spreadsheets and FileMaker and 4D and some access stuff and they would just kind of mishmash it all together and then re-output it as spreadsheets and data dumps and then put it back in.

So it was very, very cumbersome, took a lot of time, very error-prone, very human-intensive. So what we helped them to do is we helped them to codify their process by using stored procedures inside of ASC to get a standardized way to do everything. And we used Savoy to build the user interface. And because Savoy is so easy to use, these non-technical people, these people who are used to using end-user databases like Access or FileMaker Pro could easily create these user interfaces with no programming. All right, so we're going to go actually do that right now.

I'm going to build for you here a customer invoice, invoice detail, complete solution, and I'm going to deploy it in less than five minutes. Ready? Here we go. All right, so we're going to do a new solution, and I'm going to call it WWDC. And here I have a list of named servers. These servers can live anywhere.

They can be on LAN, WAN, they can be anything that you want. I have one here that is a Sybase database called Example Data. And down here this shows me all of the tables that are inside of that named connection database. So I'm going to choose to create two forms, one based on customers and one based on orders. Actually, sorry, customers.

Okay, so two tables. So I click OK. Now this will go and actually interrogate the database. So these are all the columns inside of the customer table. So let's pick some here. I'm going to say OK. And these are the ones inside of the orders. Let's pick some columns here. OK. Now, I'm going to come out of this data design mode.

Backspace over this character. As soon as I leave this field, it's automatically committed and written to the backend database. So that's pretty cool. So I have my customers and that works the same way. There's two different tables. Let's come here. And I can go ahead and use my keyboard if I want to and make these bigger or smaller by the keyboard. All right, so that's all fine and good. But now let's go ahead and do something interesting. So I have the order header, but now I want to see all the details. Just one quick question, though. First, how much SQL did we write so far? Okay.

Nothing. That's the fun part, right? That's where the knowledge worker can get in here and create these forms and these applications that they need to get their data done and not have to call up IT and go, oh, by the way, you got that thing done yet. All right? So we want to now join things together.

All right? How many of you want to really tutor these knowledge workers in how to do SQL joins? Anybody? No? Probably not. Okay. So I'll show you the Savoy way of doing things. So we're going to go back into our data designer mode here, and we're going to come up, and we have a thing called a relation.

and David Koehn, and I'm going to choose a primary key. It shows me all the columns. I'm going to choose customer ID to customer ID. And in this case, it's going to be an equity join or an equal join, but I can do greater than, less than, not equal to, and I can have multiple predicates, multiple key fields.

I can do cascading deletes optionally just by clicking a checkbox. So I click OK. Now I'm also going to do another one. I'm going to go from order to order details. Here's where it gets interesting, right, because they're named connections. So this one on the left-hand side could be MySQL.

And on the right-hand side, I could join to an Oracle database or a Sybase ASE database or a Sybase ASA to MySQL, any combination that you want to. So you can actually join data across multiple vendors' databases and have it all on one screen. So we're going to go from order to order details based on order ID to order ID.

All right, click OK. Now I'm going to click and drag, move these objects, and now we want to show all of the order details for this order below it. So we have a structure that's called a portal. So this is what this object is, and it shows me these are the valid relations.

It knows that I'm on the orders table. It knows there's only one valid relation, so it only shows me one valid one. Let's pick these columns, click OK. And now I have this portal structure. I can make it bigger. So now when I come out of my design mode, I now have all the children records.

and the order details for this customer.

Okay, anyone want to write that SQL statement? No, probably not. Me neither. All right, here's the Savoy way of doing it. We put a tab panel object on there. And it says, okay, here's customer to orders, and there's a form called orders that's based on that join. So that's all we need to do. We say yes, use that form. Here's my tab panel.

I'm going to pull it out here, come out of my data mode. Now I have this customer has six invoices. This one has 14, this has 8, this has 19, this has 14. And I can go through here and I can edit this data even though it's three tables away. And how much SQL did I write? Zero. All right.

I don't have time to show you all of the really nice user interface things that you can do. This is obviously a really simple example, but you can make it look really pretty. Now let's deploy it, okay? So now we've built it. It's beautiful. This is our app. Now I need to deploy it worldwide.

Okay. With some other project, like desktop databases, right? It's a sneaker net install or a network install or a ghosted image install. With Servoi, it's point a web browser to your Servoi application server and push the button. We use Java Web Start technology. So what happens is as soon as I click, everything happens completely outside of the browser, independently of the browser using Java Web Start.

And I say start. Now this Java Web Start application is Self-healing. It will check with the server every time it's launched, and if there's a new version, it will self-update and continue to launch. So here's my two solutions. There's a CRM and the one that we created called WWDC.

and here on my client is WWDC. Just like it was Everything works just the same. I can go to my customer's form. Here's the embedded customer's form, and it works just the same as it did in site of the developer. This can be deployed over the LAN. This can be deployed over the WAN.

I built it in less than five minutes and deployed it. Now, Bob, how about things like network latency? There is a site that you can visit, and this is going to be... DemoServoy.com:8080. Now if this looks familiar, this is a server that's running in Amsterdam. Notice it does the same thing. It goes and gets a client.

And you can run this from your own network if you want to. Just to test the network latency. Is it fast over network? It's coming, coming, coming. Here it is. All right. And we're going to go ahead and load up a solution. And it's opening up right now.

So once the solution loads, it'll run as fast as it does on the network. Here's the CRM demo. This is the demo that we ship with as a sample application. And we'll go here to the company's form. I will click on this detail. And as you can see, all the controls are native Aqua.

Okay? If you were to deploy this on a Windows machine, all of the controls would be native Windows. If you deployed it on a Linux machine, all the controls would be native Linux. If you did it on a Solaris machine, all the controls would be native Solaris. Okay? No coding.

No changes. Ready to go. This is data coming from Holland. This is live data. So let me just scroll through this. Data one at a time for you. And you can see that tab panels and all, it goes very quickly even over a network this far away. All right? And one more thing in closing. Because I know we want to get to some Q&A.

I want to give you a chance to try out Savoy on your own. After this speech, if you would like to give me your business card, I will send you a copy of the reg code for no charge.

That's about all I got, so I stick to my time frame. Thank you very much. Do see me afterwards and I will be happy to get you a copy. Thank you.

Okay, I think right now what I'd like to do is just point out that we are committed to this platform. We're going to be continuing to enhance and the value that we add to this is rock-solid industrial strength database technology on a very, very high-performing and low-cost platform. You can get more information from myself, Mike Azevedo at Sybase, or Darryl Salas. You can contact these, any of us, at any time.

We have a version of the Adaptive Server Enterprise available on our website at sybase.com/mac. It's a free download of our developer's edition for the Mac, and it's -- I think the current version that's out there is 12.5.2. I may be wrong. It might be 12.5.1. All of our documentation is available online. You can reference HTML, the HTML pages. If you have any question about the syntax of a command or some topic related to ASE, you can get that.