Actian Community Forums - Blogs - teresa

Obsolete Ingres Network Protocols to be removed in the next major Ingres release

teresa — Wed, 14 Dec 2011 21:54:18 GMT

Over the past decade TCP/IP has become the industry standard protocol. To streamline our development and support processes, Actian Corporation will drop support for a number of obsolete network protocol drivers in the next major release of Ingres (post Ingres 10.1). These protocols are no longer used and in many cases have become unsupportable. A newer version of some of the drivers is now available. While these changes do not affect the current or any past release of Ingres, the announcement is being made now to inform our customers. If a dropped protocol is one used in your environment (see list below), please contact Actian Support to identify a migration plan. This announcement will be formally provided in the 10.0.1 Service Pack and 10.1 READMEs currently under development.

This document discusses the protocols to be dropped and also provides a detailed list of the protocols that will continue to be supported.

One of the protocols, wintcp on Windows, has been deprecated for a couple of releases. Deprecation is different from (and less severe than) being dropped. “Deprecation” means that the protocol is still available but receives no new enhancements and minimal maintenance. The newer driver (tcp_ip in this case) should be used instead. “Dropped” means that the protocol will no longer be available. Note that beginning with Ingres 9.3, the protocol wintcp has been upgraded automatically to tcp_ip during installation. Other dropped protocols, if currently used (which is very unlikely), must be changed manually.

Note: All platforms continue to support the industry standard protocol TCP/IP (default is tcp_ip on Linux, UNIX, and Windows; tcp_dec on VMS; and tcp_ibm on the mainframe). Other supported protocols are listed below.

Network Protocol Drivers Being DROPPED

Windows:

lanman – Microsoft Lan Manager
nvlspx – Novell SPX/IPX
wintcp – Winsock 1.1 TCP/IP

UNIX, Linux:

async – BLAST serial protocol
decnet – DECnet (still used and supported on VMS, but not from UNIX)
iso_oslan – ISO OSI Local Area Network
iso_x25 – ISO OSI X25
nvlspx - Novell SPX/IPX
sna_lu62 – SNA LU62 (was available only on Oracle/Sun Solaris, HP-UX, and IBM AIX)

VMS:

async – BLAST serial protocol
nvlspx - Novell SPX/IPX
sna_lu0 – SNA LU0
tcp_wol – Wollongong or Multinet running Wollongong emulation TCP/IP

Network Protocol Drivers Still SUPPORTED

Windows:

tcp_ip – Winsock 2 TCP/IP

UNIX, Linux:

tcp_ip, sock_tcp_ip – TCP/IP including IPv6 support
tcp_ipv4, tcp_ip (if IPv6 not available on OS), sockets (if HP-UX TLI used for tcp_ip) – TCP/IP (v4 only)
tli_tcp_ip or tcp_ip – TCP/IP using Transport Layer Interface (TLI) rather than sockets (HP-UX only)

VMS:

decnet – DECnet (built into VMS OS)
tcp_dec – TCP/IP Services for OpenVMS, Multinet TCP/IP, and TCPWARE

Interested in Learning more about OpenROAD

teresa — Tue, 30 Aug 2011 15:47:30 GMT

There will be two webinars in the coming weeks around OpenROAD. The first one will be an introduction to the latest GA release, OpenROAD 5.1, and the second one will preview features we are working on for OpenROAD 6.2.

Details around both sessions are below.

Please come join us in learning more about OpenROAD.

If you have interest in addition additional OpenROAD webinars, please note a topic in the comment section and we'll make every effort to host additional webinars that cover the content you are interested in.

13 Sept 8am PDT & 4pm PDT
Title: OpenROAD 5.1 New Features
Presenter: Sean Thrower
Abstract: OpenROAD 5.1 is now available! Join Sean Thrower, OpenROAD Engineering, for an in depth look at the new features and functionality included in OpenROAD 5.1

Hear about the key features of OpenROAD 5.1

General-purpose system classes for XML support
- Export your application in an XML based export file format
- Better track changes made to your application
HashTable classes to improve lookup speed for objects
Improvements to the Integrated Development Environment
New SessionObject attributes

and much much more.

Register at Webinars and Events - Ingres

20 Sept 8am PDT & 4pm PDT
Title: OpenROAD Displays with no-code Gradients, Roundels, Highlighting†, Multi-Image Bitmaps, and More—it’s Open Season!
Presenter: Sean Thrower
Abstract: OpenROAD 6.2 is under development. Join Sean Thrower, OpenROAD Engineering, to see how your OpenROAD displays can be enhanced with the features planned for OpenROAD 6.2.
Display styles change, enduser tastes evolve, eventually each product gets trapped in its own display cabinet…

But with customer collaboration driving change, and some lateral thinking, the future can change too—in the coming OpenROAD release you can map your display scheme (defined as a set of bitmap images) chosen without lock-in to any development product, directly into the frame display: fields can display the corners you want, gradients can be of any orientation, and include special effects; a single bitmap can support fields of any size; bitmaps can contain multiple images, for smart highlighting, three-way selection, embedded dropdown—and all of this out of the box.

† (ok, maybe a line of code to switch the highlighting ...)

And you can capture, image-search, manipulate and apply your bitmaps at runtime.

And more. And more to come...

Register at Webinars and Events - Ingres

Update: The webinars were recorded and are available for viewing at Webinars and Events. All questions asked in both presentations are available in the available recording with answers. Hope the presentation material is beneficial.

Looking for an easy to install Ingres ODBC Driver Package

teresa — Tue, 21 Jun 2011 21:01:18 GMT

The standard method for installing either a 32-bit or 64-bit Ingres ODBC Driver Package is to download the appropriate Ingres distribution and perform an Ingres Client Install. For explicit instructions on doing an install of this nature, see Getting the ODBC Driver. There are a few gotchas when performing a 32-bit ODBC Driver install on 64-bit Windows as the 32-bit ODBC Administrator is located in a non-obvious location. For more details, see Using 32-bit ODBC on 64-bit Windows.

To make this process a bit easier, the DBA Tools Package, Ingres DBA Tools, has been updated to include the following items:

Added a new prompt confirming that the user should set their character set to UTF8 if connecting to VectorWise
Added ODBC into the install
Added a shortcut to the 32-bit ODBC Administrator

Hopefully this new package will make life easier for users who just need the ODBC Driver on the Windows platform.

Accomplishments in OpenROAD Sprint at the 2011 UK IUA

teresa — Wed, 15 Jun 2011 21:34:58 GMT

Members of the OpenROAD development team, Bodo Bergman, Brigitte Duplenne, and Joe Kronk along with Kim Ginnerup, Matt Rendell, Roy Deal Simon, and Oliver Oyston participated in an OpenROAD Sprint June 4th, 5th, and half-day on June 6th in Slough, UK. Fun and good times ensued while accomplishing a lot.

The OpenROAD Enhancement queue was thoroughly reviewed looking for potential projects that could completed in two days. Joe, being his usually overly optimistic and enthusiastic self, selected way more projects for consideration than were doable. The enthusiasm from the team that gathers for the Sprint is admirable as they start early and work late to maximize their time together.

An incredible amount was accomplished at the Sprint.

4GL projects implemented were:

Validate inputs to check for empty database name before connecting to new database in Query tab.
Change BgColor of ‘Database’ and ‘Table or View’ entry fields in the dialog titled ‘Select a Database Table’ from gray to white to indicate that you can type into these fields.
Implement sorting by clicking on a ‘Table Selection:’ frame’s header column to order the rows in the display table. Allow the user to sort to two levels of ordering.
Enclose literal strings in quotes when assigning new values in the debugger.
Implement an 'always on top' option for the property inspector.
Create a new application or component when right clicking in the applications or components pane. Currently the option 'new' is not available on the context sensitive menus opened by right mouse click.
When on the components pane, click on the 'new' button, a popup for creating a new application gets opened instead of a popup to create a new component. Either the 'new' button should be dimmed, when the components pane is activated or when clicking the 'new' button you should get a list of possible components to create. The solution implemented was the ’new’ button in the tool bar is dimmed if the component frame is activated. This will prevent the user from choosing the ‘new’ button expecting to create a new component and being presented with the new application dialog instead. Instead of only adding the ‘new’ menu item to the context sensitive menus for the application and components pane, we filled out the context sensitive menus with all the corresponding toolbar items which made sense for the particular menu.
While transferring components between machines, Kim almost overwrote a component by accident using the export dialog. This occurred because the screen layout led him to enter in a filename first before changing the export format type. This filename entryfield was not big enough for him to see that file extension had changed. We decided to take the time to fix these problems by changing the screen layout so you would change the file type first before entering the filename. The filename field was enlarged to allow most files names including the full path to be seen. We made the changes in such a way that all similar type dialogs benefited.
Suppress the display of “application name!” in front of the defined attributes and methods in the class window when one class inherits from another.

3GL Projects worked on but incomplete were:

Provide the developer with a list of running FrameExecs.
Provide a way to break out of tight loops in the 4gl by allowing to break the flow of 4gl instructions and stopping at that point in the debugger.
Fix the runtime so that two levels of property options menu work properly on portlets.

Large projects that were continued at the Sprint were:

Provide developers with an intellisense editor.
Upgrade an ABF application to OpenROAD and allow some of the frames to be rendered in HTML using HTML5 communicating directly with the business logic in the OpenROAD Server.

Some other projects, beyond the scope, could only be dreamed about were:

Allow the developer to view a single script that can be view as a processed script, a field script, or as a mixture of scripts without the need to pick on style over another.
True multi dimensional arrays ( Filling contiguous block of memory).

Even though the Sprint was officially over, Joe faced with a 3hr flight delay and 10hr flight home sitting in a seat with a broken movie screen, implemented one more project. Details below:

Add the current selected application name next to Components (on top of the component panel). Currently, the behavior is Component(s) of . This feature is still not quite complete as he would like to also change the applications pane title to Application(s) of .

Now back to the real world where the projects all need to be written up on the OpenROAD project page and those that are complete need to be submitted into the development codeline if not done so already. The features discussed above that are fully implemented will be scheduled in the OpenROAD 6.2 release. For those projects for which a project page exists, I’ve linked the aforementioned projects to the project page. As the project pages are completed, I’ll revisit this article and update with the remaining links.

Congratulations to all the participants for a job well done!!! It is clear from all that was accomplished that many hours were spent implementing the completed projects and making a good start on the other projects. Based on feedback, I know everyone is already looking forward to the next Sprint.

UK IUA 2011 Ingres Products Future Features Agenda Topic Was a Success

teresa — Fri, 10 Jun 2011 20:18:00 GMT

An exciting new agenda topic was added to the 2011 UK IUA this year allowing attendees to suggest and vote on features to add to the Ingres family of products. The Ingres family of products include but not limited to Ingres, OpenROAD, and VectorWise. This new informal gathering was very well received with so many suggestions that we ran out of time to discuss. Even if you were not able to bring your proposed feature before the group the ability to get your feature added to the list was still possible and many features were added to the list during the closing Wine & Cheese Reception. Thanks for providing me with a glass of wine so I could still take notes while also enjoying the benefit of the closing reception. :)

Hopefully I’ve managed to properly document all of the features proposed at UK IUA 2011 Ingres Products Future Features Vote - Ingres Community Wiki.

Please don’t hesitate to let me know if I’ve incorrectly noted any feature or inadvertently left off an item.

In my opinion this was a very useful and welcome addition to the agenda and I hope that it is repeated in future conference years. It is always very helpful to understand what the pain points our customers are experiencing and what we can do to assist them in the future.

Looking to enable your OpenROAD Application to handle Unicode?

teresa — Fri, 03 Jun 2011 00:35:31 GMT

Are you beginning to plan your move to a Unicode environment? Looking to understand what will be involved in migrating your OpenROAD application to handle Unicode data?

OpenROAD 6.0

OpenROAD 6.0, Windows only, will provide transparent Unicode support; however, depending upon your application there may be some minor code changes involved. What transparent Unicode support means is that you do not need to modify your application data types, although you may need to change your schema data types (DDL). You must use the UTF8 character set. It is usually a good idea to convert the schema (DDL) to use the Unicode types such as NVARCHAR even if you will be using Ingres as the backend, although it’s not necessary. The conversion of the schema (DDL) is mandatory for use with Enterprise Access so if your solution runs against multiple databases, changing the schema (DDL) in all cases makes for consistency.

Preparing for the Migration

The recommendation, as you are testing out your changes with either an Ingres DBMS or Enterprise Access, is that you utilize a separate test installation to not adversely impact your development environment. Be aware that if you change your DBMS server character set to UTF8, all client applications must utilize a UTF8 character set as well. You will need to migrate your application from your current non-UTF8 environment or non-Unicode environment to a UTF8 environment/Unicode database. The XML feature provided in OpenROAD 5.1 will assist in this migration.

If running against an Ingres 9.2 or later database server, you can utilize the UTF8 character set and not change the underlying DDL as the UTF8 character set allows you to store Unicode data in char/varchar/long varchar data types.

If running against Enterprise Access 2.7, the only solution that has been fully tested at this point with OpenROAD 6.0 is MS SQL Server and you will need to modify your DDL to utilize Unicode data types.

Migration Steps

The first step to migrate to OpenROAD 6.0 Unicode/Multibyte support is to change any OpenROAD varchar(1) to varchar(3) and varchar(2 ) to varchar(6). One of the customers who uses the OpenROAD Unicode version does all of their development on OpenROAD 4.1/OpenROAD 2006. They then export the applications from the OpenROAD 4.1/2006 environment and import them into OpenROAD 6.0. To this day they still do their primary development in OpenROAD 2006 SP1. (This technique pre-dated the availability of the XML export capability of OpenROAD 5.1. In OpenROAD 5.1 you can export and import using the XML format as an option. OpenROAD 6.0 has this same capability.)

There should not be any need to change the data types of any of your OpenROAD program variables or widgets. This will be done automatically by the OpenROAD 6.0 runtime.

The biggest change that you will need is if you use string objects. The default structure to store a string object in a pre-OpenROAD 6.0 release is a table that appears as follows:

In OpenROAD 6.0 this structure will be defined as follows:

You will need to provide your own tools to unload any string objects persisted in the 4GL catalogs. OpenROAD 6.0 does not provide any conversion tools for this.

You will use w4gldev backupapp to reload the 4GL source code into the catalogs. That utility will take care of any idiosyncrasies when using the II_CHARSETxx=UTF8. OpenROAD 6.0 is also capable of support Multi-byte character sets such as Simplified Chinese (II_CHARSETxx=CSGBK, cp936).

Summary

OpenROAD 6.0 will provide transparent Unicode support, allowing you to enable your applicable to handle Unicode data. We anticipate OpenROAD 6.0 entering QA in Q3 upon completion of the GA status of the remaining OpenROAD 5.1 platforms (HP-UX PA_RISC and Linux). The GA date will depend upon how the QA cycle progresses.

To provide a jump start to the process, we have made a preview of OpenROAD 6.0 available utilizing OpenROAD Workbench Express. This will allow you to test your application in a development environment to see what changes may be required going forward. Workbench Express is only supported via the forums and does not provide the capability to build images.

Attached Thumbnails

Using ODBC applications on 64 bit Windows

teresa — Tue, 10 May 2011 16:17:39 GMT

Are you running applications on 64 bit Windows? Are you frustrated when you discover that your 3rd party application is a pure 64 bit application requiring an Ingres 64 bit ODBC Driver but finding out that only a 32 bit Ingres ODBC Driver exists?

Your frustration can come to an end as Ingres has released a 64 bit Ingres ODBC driver with Ingres 10. In the ever increasing 64 bit architecture world, more and more 64 bit specific ODBC application interfaces are being deployed. A 64 bit Ingres ODBC Driver is included with the 64 bit Ingres Windows release available for download at http://esd.ingres.com/product/Ingres...Windows_64-Bit. The ODBC Driver provided with this release will provide you with the ability to interface with 64 bit Office 2010, 64-bit Dyalog, and other 64 bit applications requiring an ODBC Driver.

If you have a need to deploy 32 bit ODBC applications on 64 bit operating systems, this is possible but the ODBC Administrator in SYSWOW64 needs to be used instead of the default ODBC Administrator as the default ODBC Administrator is a 64 bit application. Refer to ODBC on 64 - Bit Windows - Ingres Community Wiki for more details on deploying 32 bit ODBC Applications on 64 bit Windows.

What’s New with OpenROAD

teresa — Fri, 18 Mar 2011 22:57:58 GMT

OpenROAD 5.1

2011 is off to a very busy start for the OpenROAD team as they strive to release the latest version of OpenROAD, 5.1, into GA status on Windows by the end of Q1 with the remaining platforms to follow. The defining feature of the release will be general-purpose system classes for XML support, to allow creation and parsing of arbitrary XML documents without the need to create additional user classes or to use external components (3GL Procedures or External Class Libraries). Providing an XML based export file format will that will be documented, human readable, produce clean differences between different revisions of a file, allow changes to be merged, will allow OpenROAD source components to be managed by many different Software Configuration Management (SCM) systems. To understand more about what is coming in OpenROAD 5.1, see Ingres Roadmap/OpenROAD 5.1 - Ingres Community Wiki.

OpenROAD 6.0

OpenROAD 6, targeted for Windows, will quickly follow the OpenROAD 5.1 release. The defining feature of this release is Transparent Unicode support. This feature supports the Ingres NCHAR, NVARCHAR and LONG NVARCHAR data types and allows an OpenROAD application to access these new data types without any need to change the underlying OpenROAD program variables. Previous versions of OpenROAD supported only single-byte character sets. OpenROAD 6 extends this support to multi-byte and UTF8 character sets. This means that there will be minimal changes to an existing OpenROAD application to support languages such as Simplified Chinese, Korean and Japanese character sets. The XML functionality that was introduced in OpenROAD 5.1 is used by OpenROAD 6 to allow the transparent migration of existing OpenROAD applications to a UTF8 environment. The transparent Unicode was implemented in a manner to reduce application migration costs by limiting the amount of application changes required. For example, a partner we worked closely in implementing the functionality was able to redeploy their 1.5 million line application with fewer than 100 lines of code changes.

Future OpenROAD Plans

Planning and early development is ongoing for the release targeted after OpenROAD 6. One of our large OpenROAD partners approached us with a requirement to enhance their application to meet stringent new corporate standards in a manner that was not possible with the current OpenROAD release. This has driven new functionality that will be available in a future release for all customers to take advantage of. The final release content is still under discussion but you can follow our plans at Ingres Roadmap/OpenROAD 6.2 - Ingres Community Wiki.

Preview upcoming features and capabilities of OpenROAD.

Previews of future OpenROAD new features and capabilities are being made available via Workbench Express, a version of OpenROAD and selected components. For more information regarding Workbench Express, see WorkbenchExpress Home - Ingres Community Wiki.

Time to say goodbye to the “ca.ingres.jdbc” package

teresa — Fri, 16 Apr 2010 17:59:49 GMT

Beginning with Ingres 2006, the Ingres JDBC Driver and DataSources classes contained in the Java archive, iijdbc.jar, under the Java package path of "ca.ingres.jdbc" were moved to the package path of "com.ingres.jdbc". The iijdbc.jar archive included with all Ingres 9.x releases also contains the original classes for backward compatibility with the note that the classes would be removed in the next major Ingres release.

The time has come to say goodbye to the “ca.ingres.jdbc” classes. Some of you may have already noticed that the “ca.ingres.jdbc” package has not been in the JDBC 4.0.x Community Previews and in Ingres 10 Community builds.

The original "ca.ingres.jdbc" package path and classes will be removed from iijdbc.jar beginning with Ingres 10. Existing references to "ca.ingres.jdbc" will need to be changed. JDBC 4.0, which is supported by the Ingres 10 JDBC driver, provides a new mechanism for loading JDBC drivers which does not require Java applications to instantiate or reference the driver class. Existing references such as Class.forName("ca.ingres.jdbc.IngresDriver") may be removed completely and the JDBC DriverManager will load the Ingres JDBC driver automatically when iijdbc.jar is included in CLASSPATH. If instantiation of the driver class is still desired, then "ca.ingres.jdbc.IngresDriver" will need to be changed to "com.ingres.jdbc.IngresDriver". Any references to DataSources which use the "ca.ingres.jdbc" package path will need to be changed to "com.ingres.jdbc".

Improving Data Load using the new Ingres 10 Batch Execution Feature

teresa — Thu, 15 Apr 2010 04:14:55 GMT

One of the new features coming with Ingres 10 is the complete support of batched statements in JDBC. The Ingres JDBC Driver has always supported the addBatch and executeBatch methods but under the covers executed each statement in the batch individually. While this worked, it resulted in less than optimal performance. With Ingres 10, a number of changes were made to the Ingres DBMS, Data Access (DAS) Servers and the JDBC Driver to utilize a feature of the Ingres communications layer to send statements across in batches, thereby reducing communications overhead. In addition, the Ingres DBMS implemented a number of optimizations to improve the processing of these batched queries. All of these changes have enabled big improvements in response time when processing large batches of statements through JDBC.

Batch execution is restricted to queries that return either a response or a row count, but no data. For example,

Statements allowed include INSERT, DELETE, and statements that return no data, such as CREATE TABLE.
SELECT statements and row-producing procedures are not allowed in batched queries.
If the DBMS does not support batch processing, the Ingres JDBC driver will detect it and automatically execute the statements individually.

Batched statements that use repeated dynamic INSERT statements (for example, through Java-based Extract Transfer and Load (ETL) tools) are specially optimized to improve performance. See draft documentation for more information on ways to improve the insert performance.

To trigger the optimizations in the DBMS Server the following criteria must be met:

Statement must be a prepared dynamic statement
Statement must be of the form “INSERT INTO……VALUES”
Any values that are expected to change for each insert must be parameterized. As with all inserts, columns can be omitted if they are nullable or have default values (including identity columns).
Parameters for the query must include only column values, other parameters (e.g. table name) are not allowed

Observed Batch Execution Performance behaviors

In testing out the functionality internally, the following behaviors were seen.

For local execution of non-dynamic statements and procedures, batch appears to have only a small performance improvement.
For remote execution of non-dynamic statements, JDBC batch performance increases significantly up to a batch size of about 100 statements.
For non-dynamic statements, there does not appear to be a significant improvement in performance for batch sizes over 100.
Batch sizes of 100 and greater reduced communications round-trips to the point that little difference was seen between local and remote JDBC execution.
For dynamic statements, performance just continues to increase as batch size increases due to the copy optimization.
The copy-optimization for prepared statements is actually very detrimental for small batch sizes. Single statement execution ran at about a minute. Doing the same thing with a batch size of two statements increased the time to between 12 and 13 minutes! Execution times then dropped to 2 1/2 minutes at a batch size of 10 statements and only regained parity at a batch size approaching 100 statements. On the other hand, really large batches went screaming fast.

Internal performance testing has shown an improvement of 24 times (193 seconds down to 8 seconds) when comparing inserting 100,000 rows using the prepared insert statement between Ingres 9.x and earlier JDBC batch support and the improved batch execution support in Ingres 10 b 121. Note that the data used internally was likely not representative of real world testing.

Turning off the Improved Batch Execution Support

This new functionality will be enabled by default with the Ingres JDBC Driver as it is expected to provide significant performance benefits; however, if for your particular environment you find it doesn’t, you can force individual statement execution by using the ingres.jdbc.batch.enabled system property to disable batch query execution.

Availability in other Clients

Batch statement execution will also be supported in OpenAPI with Ingres 10. Future Ingres versions will extend this capability to other drivers.

How can I get access to the new functionality?

The feature is now available for testing and was recently released to the community in Ingres 10 b 121. The feature is enabled in JDBC Driver version 4.0.1 which is either available as part of the Ingres 10 b 121 release or from the JDBC 4.0 Community Preview download. More information regarding the features in the 4.0.x JDBC Driver can be found at JDBC 4.0.x New Features.

If you are interested in the details of the implementation in Ingres, the design specification can be found at here.

Sample programs demonstrating the batch capabilities for Java and OpenAPI can be found at Ingres Coding Samples.

Summary:

Performance testing so far has shown a significant improvement in processing batched rows with the largest improvements being with larger batch sizes.

Smaller batch sizes, say 10 records per batched query, don’t generate as much improvement due to the overhead of setting up the optimizations in the DBMS that offsets the performance improvements in sending the data in batch across the communications pipe. In fact, better performance for this case is gotten by using individual insert statements in a batch rather than using prepared statements because individual statements don’t invoke the new optimizations in the DBMS.

JDBC batched statement execution does not exactly match the performance of the Ingres Copy command but it is a significant improvement over Ingres 9.x and earlier.

Many factors can come into play when using the feature and generating performance numbers, from the table structure to the row size.

To benefit from this feature requires an updated JDBC Driver (minimum 4.0.1) and Ingres 10 b121 DBMS and Data Access (DAS) Servers.

We are very interested in having the functionality tested by some real world applications to determine whether the changes made are on the right track or do we need to step back and approach from another angle.

Feedback on your testing can either be provided to the forum or via a Service Desk issue. Any and all feedback greatly appreciated.

Ever have trouble identifying when a feature was introduced in Ingres?

teresa — Tue, 02 Mar 2010 22:03:12 GMT

It's always challenging to discover what features were released in a particular Ingres version when trying to plan a migration from one release of Ingres to another.

This document attempts to complement the Ingres Migration Guide by not only providing the list of features but also including the associated project page if one exists on the Community Wiki. In some cases, the release will predate the move by Ingres Engineering to make the design documents of new features readily accessible to the community. The Ingres Migration Guide should always be the first point of reference when research is underway concerning a migration from one Ingres release to another but hopefully the information provided here will also be beneficial.

Per Keith's great comment, the Ingres Product Roadmap is availabe at Product Roadmaps. As Ingres 10 moves closer to a GA status, a similar page/layout will be provided and added to here.

How to Locate Information About the Ingres .NET Data Provider?

teresa — Tue, 02 Mar 2010 21:48:22 GMT

Ever wonder how to find more information on the Ingres .NET Data Provider? There is quite a bit of information on the Ingres Community Wiki relating to the Ingres .NET Data Provider and using .NET with Ingres.

Most of this information is centrally located at Ingres .NET Development Center. We try to ensure all content on the wiki related to .NET and Ingres can be accessed from this main page. I’m sure we don’t manage to link up everything but we do try.

A summary of the type of information that can be found here follows.

The .NET Framework supported, the assembly name, assembly version needed for a particular .NET Data Provider version.

Accessible from this page are:

• Articles relating to using .NET with Ingres and integration of Ingres with .NET Applications. To directly check out all articles see Ingres .NET Articles.
• Coding samples relating to using new Ingres features from .NET. To directly check out all coding samples see Ingres .NET Coding Samples.
• Presentations around .NET and Ingres. To directly check out all presentations see Ingres .NET related presentations.

More recently the section was updated to clearly document what features where introduced in what .NET Data Provider version.

We are always looking to add new content to the wiki and encourage you to submit ideas for new content or add new content yourself.

Outside of the Community wiki, the Connectivity Guide in the Ingres product documentation is the base reference resource for the .NET Data Provider.

Questions can always be posted to the Data Provider Forum.

Feedback is always welcome.

How to Locate Information About the Ingres ODBC Driver?

teresa — Tue, 02 Mar 2010 21:36:52 GMT

Ever wonder how to find more information on the Ingres ODBC Driver? There is quite a bit of information on the Ingres Community Wiki relating to the Ingres ODBC Driver and using ODBC applications with Ingres.

Most of this information is centrally located at Ingres ODBC Development Center. We try to ensure all content on the wiki related to ODBC and Ingres can be accessed from this main page. I’m sure we don’t manage to link up everything but we do try.

A summary of the type of information that can be found here follows.

Accessible from this page are:

• Articles relating to using ODBC applications with Ingres and integration of Ingres with ADO, MS Access, etc. To directly check out all articles see Ingres ODBC Articles.
• Coding samples relating to using new Ingres features from ODBC. To directly check out all coding samples see Ingres ODBC Coding Samples.

More recently the section was updated to clearly document what features where introduced in what ODBC Driver version.

We are always looking to add new content to the wiki and encourage you to submit ideas for new content or add new content yourself.

Outside of the Community wiki, the Connectivity Guide in the Ingres product documentation is the base reference resource for the ODBC driver.

Questions can always be posted to the Driver Forum.

Feedback is always welcome.

Minor Ingres Community Wiki Refresh

teresa — Tue, 09 Feb 2010 22:33:36 GMT

The Ingres Community Wiki has underwent a minor refresh to hopefully help folks find content a bit easier. Check out the new Main Page.

The main changes were to cut down on the number of content boxes, update descriptions for the remaining content boxes, and add a brief list of the type of information that could be found in the particular content box.

Another small change was to bold the "Drop Downs" to highlight that they exist as I was told my a number of folks that they scrolled right passed them and then tried to figure out where to locate information on the wiki using the content boxes and proceeded to get lost.

Other minor updates were made to some of the Application Development landing pages to also help improve the ability to locate information.

This continues to be a work in progress as we work on improving the Community Wiki.

Any comments and suggestions you may have are most welcome. The comments can be around layout, organization, or what is missing.

What’s Happening with the Ingres JDBC Driver?

teresa — Fri, 05 Feb 2010 16:36:01 GMT

The Ingres JDBC team has busy working on new features in the Ingres JDBC Driver for Ingres 10 release. Enhancments include:

Adding Support for the following JDBC 4.0 API features:
- Automatic loading of java.sql.Driver
- National Character Set Conversion Support
- Enhances Support for BLOB and CLOB
- Wrapper pattern
- New Scalar Functions
- SQLException enhancements
- JDBC API changes to existing JDBC interfaces
- SQL/XML and XML support
- Connection Management

For more information on the Ingres support of the JDBC 4.0 API features, see JDBC 4.0 API Features Implemented.

A Community Preview of the Ingres JDBC Driver (iijdbc.jar) can be found at Community Preview Download Area.

Boolean Data Type Support.

For more information regarding Ingres’s support of the Boolean Data Type, see Boolean Data Type Support.

A Community Preview of the Ingres JDBC Driver (iijdbc.jar) will be available in the future that exposes this support. An Ingres 10 DBMS and Data Access Server (DAS) are a must to exploit this feature.

Batch Execution Support.

Batch processing (batch execution actually) is currently supported in the Ingres JDBC Driver but under the covers statements are not actually batched but instead are done as Singleton queries which undermine the performance improvement expected when batching queries. The feature was implemented in this manner due to the lack of support in the Ingres DBMS for batch processing. With Ingres 10, the DBMS will be adding capabilities to handle batch processing and the JDBC Driver will be modified to take advantage of the new Batch feature. This enhancement should significantly improve batch processing in the Ingres JDBC Driver.

For more information regarding Ingres’s support of Batch Execution in Ingres 10 and the JDBC Driver, see Batch Statement Execution Performance.

A Community Preview of the Ingres JDBC Driver (iijdbc.jar) will be available in the future that exposes this support. An Ingres 10 DBMS and Data Access Server (DAS) are a must to exploit this feature.

Future blog entries will discuss new updates to the JDBC Driver and Community Previews of the new functionality.