• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (13)

1 localhost commented Permalink

I'd like to see DBPing as a supported tool... It helps in creating OLEDB connections strings besides being very useful for debugging purposes.

I'm not sure about the current status of sqlidebg, but it's also a very nice feature.
From the customers point of view, they normally complain about the integration between IDS and MS SQL Server (linked servers for example). It's hard to understand what's going wrong. Any features that would help this would be nice.
I agree with the inclusion of drivers for the various languages/technologies that we support.

2 localhost commented Trackback

Thanks Fernando, duly forwarded.

3 localhost commented Permalink

I'd like to see a more customer based installation routine. So that I've only the parts of software that I need. Espaccially on Unix-Systems where we roll out odbc-libs while we using the Perl/DBD/ESQL way for connects.

And all the other stuff you've said :-)

4 localhost commented Trackback

Fernando, a reply from the client architect, Shesh...

SQLIDEBUG is now again part of CSDK (for a moment it was stopped shipping with CSDK). Compatibility with SQL Server Linked server is still an issue and we are working on resolving defects logged in this area. However we got to change this model and got to be more proactive testing in house and resolving any issues. So this will definitely go in my list and also DBPing request.

5 localhost commented Permalink

Full support for .NET 2.0 new database features and total integration with Visual Studio 2005 server explorer.

6 localhost commented Permalink

In the future I like to see a full gcc support for esql/c for the most Unix platforms (like AIX/HP-UX and Solaris)


7 localhost commented Trackback

I would like have a driver for J2ME and .NET Mobile Devices.


8 localhost commented Permalink

A single CSDK/I-Connect product.

All the libraries of I-Connect are already part of CSDK. THe only difference is the ESQL/C pre-processor that is extra in CSDK and not in I-Connect. I'd like to see both these as a single product. We don't need two of the nearly identical products.
More coming ...

9 localhost commented Permalink

I’m writing ASP.NET applications so I’ll concentrate on .NET features.While CSDK 3.00 is a great progress for.NET there are still many things missing (in comparison to .NET drivers for DB2, MS SQL, Oracle databases):.NET provider:- support for Multiple Result Sets – in documentation it is supported feature but it doesn’t work;- make DBCommandWrapper.DiscoverParameters metod behave as MS SQL equivalent (for example it differs in counting procedure parameters);- in future: pure native .NET driver; it will allow to decouple .NET driver from the rest of CSDK (like jdbc driver) and easier support for new platforms (64 bit, Itanium); also better performance;- better implementation of reader.GetDecimal (current one fails if DBMONEY is not set correctly; strange!)IBM database Add-ins:- more mature version (currently many places are referring to DB2 instead of Informix, non-working options, properties of DB2 database objects instead of Informix properties);- drag & drop from Server Explorer to web form (most important);- support for Visual Studio 2008 which is currently in public beta 2 version;- possibility to view existing triggers and indexes in Server Explorer;- wizards for creating tables, views, indexes.

10 localhost commented Permalink

Hi Shesh,

I’ve used “Multiple Result Sets” in different meaning. It comes from subtitle in the following article:http://msdn2.microsoft.com/en-us/library/bh8kx08z(VS.80).aspx and from description of IfxCommand.ExecuteReader.This is not MARS (I know that in CSDK 3.0 MARS works perfectly). So I explain this in more detail.According to CSDK .NET provider documentation:- IfxCommand.ExecuteReader - "The query can return multiple result sets";- IfxDataReader.NextResult: "When reading the results of batch SQL statements, advances the IfxDataReader object to the next result"I’ve tried to test this. To do such a test I’ve wrote an SQL string containing two select statements (without parameters) separated by “;”. From this test I know that it does not work: I’ve got error -555 from IfxCommand.ExecuteReader.I suppose that data adapter method Fill is using ExecuteReader. If so then this is the reason why IfxDataAdapter fails with the same error on the same SQL.This is unfortunate because in many Microsoft training materials and samples typical approach is to have more than one select statement in SQL string and to populate dataset using Fill. With MS SQL provider end result is such that dataset contains as many datatables as many selects are contained in the SQL.Porting code from MS SQL to Informix would be easier if IfxDataReader work according to the documentation.

11 localhost commented Permalink

In response to Shesh:“DBCommandWrapper.DiscoverParameters”I’ve created the same procedure in MS SQL and Informix:MS SQL:CREATE PROCEDURE CustOrdersOrders @CustomerID nchar(5)ASSELECT OrderID,OrderDate,RequiredDate,ShippedDateFROM OrdersWHERE CustomerID = @CustomerIDORDER BY OrderIDInformix:CREATE procedure custordersorders(fCustomerID char(5))returning integer, date, date, date; Define fOrderId integer;Define fOrderDate, fRequiredDate, fShippedDate Date;Foreach SELECT OrderID, OrderDate, RequiredDate, ShippedDate Into fOrderId, fOrderDate, fRequiredDate, fShippedDate FROM Orders WHERE CustomerID = fCustomerID ORDER BY OrderID

Return fOrderId, fOrderDate, fRequiredDate, fShippedDate With Resume;End Foreach;End procedure;
In Informix DeriveParameters returned collection of 6 parameters, while in MS SQL only 2.First 2 parameters were almost the same. Additional 4 Informix parameters were apparently taken from return values altough "Direction" flag was set to Input.First parameter was named "RETURN" in Informix and "RETURN_VALUE" in MS SQL.

12 localhost commented Permalink

In response to Shesh:“One should be able to install only .NET Provider from CSDK bundle”. Ok, agreed. However CSDK package is much bigger when it contains .NET provider and Visual Studio Add-ins.In the future this Add-ins will have more features so it become even bigger. Not all people needs this Add-ins (minority) so ideally it would be good to have separate package with just .NET provider and Add-ins.IBM can’t do that because .NET provider is dependent on core CSDK. In case of separate packages it could happen that customer installed .NET provider with different core CSDK. I think that Informix support wants to avoid such a scenario.So ideally the best would be to have separate package with pure .NET provider and Add-ins independent of core CSDK.I know that writing new driver is a big challenge and above reason doesn’t justifies it enough.The only thing which justifies it is portability: one version of .NET provider for Windows 32-bit, Windows 64-bit (btw: there is no csdk for it at all), Windows on Itanium.As for the performance: I apologize, I was just repeating other peoples opinion. I do not have any bad experience myself.

CSDK 3.00.TC2 – I haven’t seen it yet. Good to know.

13 localhost commented Trackback

Robert, please can you email me.. http://www.ibm.com/contact/employees/us/Shesh would like to check a couple of details of the defineParameters test case with you.Thanks.. Guy

Add a Comment Add a Comment