How about a LIMIT clause (LIMIT row_count OFFSET offset) that can be used to
constrain the number of rows returned by the SELECT statement like MySQL,
PostgreSQL.

Dorn B.


----- Original Message -----
From: "Sosnowski Robert" <robert.sosnowski@bzwbk.pl>
To: <informix-list@iiug.org>
Sent: Wednesday, February 11, 2004 05:14 AM
Subject: Re: Whatcha' wanta have?????


> As for 9.6 I see 2 important things:
> 1. Web services
> 2. BLOB literals
>
> ad. 1
> Idea behind stored procedures in SQL database is very similar to that of
Web
> services. So it seems quite natural that database should expose its stored
> procedures as WEB services.
> I see that this is:
> - useful even in Intranet,
> - becoming standard.
> Currently in my company we will migrate our database application to .NET.
> Even for me as the beginner in .NET concept of exposing application API in
> Web Services instead of stored procedures seems straightforward. It would
be
> even easier if database would support it natively.
>
> It is becoming standard. DB2 and Oracle already have it. Also BEA Tuxedo
> middleware. MSSQL and Sybase announced. Don't let Informix be an isolated
> data island!
>
> There are some peculiarities with Web services: there are two different
> reference platforms:
> - .Net
> - Apache-Tomcat (java).
> As Informix works not only on NT then choice is clear. I'm only afraid
about
> java: I would prefer implementation not based on java if possible. I just
> prefer simpler but faster and more reliable solution.
>
> DB2 also have interesting extension: you can use web service similar as
> stored procedure.
> In Informix it extends stored procedure implementation method. Currently
> Informix have:
> - SPL;
> - J/SQL (Internet Foundation only);
> - C databalades.
> I want to add to this list:
> - Web Services.
>
> ad 2.
> For BYTE, TEXT, CLOB, and BLOB types there are no literals. Why? It just
> complicates simple things.
> For TEXT and CLOB it would be the same literal as for char(30000) column.
> For BYTE and BLOB it have to be some hex literal.
>
>
>
> Best Regards,
>
>
> Robert Sosnowski
>
> IT specialist CK BZ WBK,
> e-mail: Robert.Sosnowski@bzwbk.pl
> ul. Pl. Andersa 5, 61-894 Poznañ
> phone +48 61 856 54 09
> fax +48 61 856 52 36
>
> >>As a mild diversion from the IDS-DB2 conversion thread, its time for one
> of
> >>my more favorite exercises. ;-)
> >>
> >>We are nearing the end of the coding cycle for IDS 9.5. We've got a
whole
> >>bunch of really cool stuff in place and - well - its time to get input
> from
> >>you guys as to what you want to see in the 9.6 release.
> >>
> >>Now, I know that everyone's favorite thing is going to be "marketing",
but
> >>I'm in development. So I need to talk features and functionality. So
> feel
> >>free to send them on in.
> >>
> >>Just an FYI - I'll be away for a while and won't be able to get email
via
> my
> >>comcast email address. But, I'll be following the newsgroup rather
> closely.
> >>
> >>Also, next week I'll be in some planning meeting. So getting responses
> back
> >>fairly quickly would really help.
> >>
> >>Thanks
> >>
> >>M.Pruet
>
>
> ===========================
> Wiadomo¶æ ta oraz wszelkie za³±czone do niej pliki s± poufne i mog± byæ
prawnie chronione.
> Je¿eli nie jest Pan/Pani zamierzonym adresatem niniejszej wiadomo¶ci, nie
mo¿e Pan/Pani jej ujawniaæ,
> kopiowaæ, dystrybuowaæ ani te¿ w ¿aden inny sposób udostêpniaæ lub
wykorzystywaæ.
> O b³êdnym zaadresowaniu wiadomo¶ci prosimy niezw³ocznie poinformowaæ
nadawcê i usun±æ wiadomo¶æ.
> ===========================
> This email and any attached files are confidential and may be legally
privileged.
> If you are not the intended recipient, any disclosure, reproduction,
copying, distribution,
> or other dissemination or use of this communication is strictly
prohibited. If you have received this transmission in error please notify
the sender immediately and then delete this email.
>
>
> sending to informix-list
>
>
> sending to informix-list
> sending to informix-list
>


sending to informix-list