Re: Whatcha' wanta have?????

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 sending to informix-list

Dorn Bhechsonggram wrote: > 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. We have select first 100 * from .... however there is no offset; noticable by its absence. I can see why; it almost makes the engine pull up the first part of the selection set anyway. I wonder if there is a smart way to do it in Informix. How do other engines avoid fetching th first 100 records just to get to the 2nd lot of 100 records?