From sityb na incluudes.com  Sun Feb  1 10:20:42 2004
From: sityb na incluudes.com (Sam Marshall)
Date: Sun,  1 Feb 2004 10:20:42 +0100
Subject: Another big STOCK PICK - SBWL (Skybridge Wireless Inc)
Message-ID: <ZBXTUXPCHOSWKBZHGLBDH@incluudes.com>

As seen on N.B.C., C.B.S., C.N.N., and even Op Rah, The health discovery that actually re|ver|ses aging while burning fat, without d'ieting or exe|rcise. This provendiscovery has even been reported on by the New England Journal of Medicine.Forget aging and die'ting forever, And it's Guaran'teed,
y
Visit Our site below:
http://www.incluudes.com/we/
y
Would you like to lose we|ight wh|ile you sl|eep,
No dieting,
No hunger pains,
No Cravings,
No strenuous exercise,
Change your life forever,
y
100% G UARAN TEED m
n
1.Body Fat Loss 82% improvement.
2.W|rinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

Visit Our site below:
http://www.incluudes.com/we/


**************************************************
If you want to get re motved
from our lpiskt please v pisit - http://www.incluudes.com/b.html

**************************************************

From daltoncharlestp na agrisol.co.uk  Sun Feb  1 16:23:34 2004
From: daltoncharlestp na agrisol.co.uk (Dalton Charles)
Date: Sun, 01 Feb 2004 15:23:34 +0000
Subject: Your lover will be happy
Message-ID: <IHNACCDOGIDLIDAJGOMOMKEFFKAA.daltoncharlestp@agrisol.co.uk>

What's up,

Only Al.pha Male Plus will grant men tonz of cli.maxes. 
At last, any guy can have many orgasms and give 
his mate the climax they want

<a href="http://usy.rty22.us/alpha/?hpsales">find out how now dyg</a></font>


<a href="http://wtn.rty22.us/alpha/o.html">no more emailz</a>

From drasnar na mineral.cz  Mon Feb  2 10:24:54 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Mon, 2 Feb 2004 10:24:54 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <01C3E976.CD8BA680.drasnar@mineral.cz>

Zdravim,

Potrebuji radu. Na RH9 mam db v kodovani 8859-2. Potrebuji jeji vystup 
dostat do prostredi phprs (www - red.systemu od J.Lukase), ktery pouziva 
kodovani windows-1250. Zkousel jsem nastavit spravny format takhlke:

Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");

Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou stale spatne. 
Poradite?

Diky.

Jirka Drasnar




From jiri.holec na ct.cz  Mon Feb  2 10:36:05 2004
From: jiri.holec na ct.cz (jiri.holec na ct.cz)
Date: Mon, 2 Feb 2004 10:36:05 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <H0000faa10c13676.1075714564.oma.apl.ct.cz@MHS>

Zdravim,

Co takhle podivat se na nastaveni php, nemas nahodou v php.ini nastavenou 
polozku default_charset na iso-8859-?.

Jirka
> 
> 
> Zdravim,
> 
> Potrebuji radu. Na RH9 mam db v kodovani 8859-2. Potrebuji 
> jeji vystup 
> dostat do prostredi phprs (www - red.systemu od J.Lukase), 
> ktery pouziva 
> kodovani windows-1250. Zkousel jsem nastavit spravny format takhlke:
> 
> Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> 
> Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou stale spatne. 
> Poradite?
> 
> Diky.
> 
> Jirka Drasnar
> 
> 
> 
> 


From drasnar na mineral.cz  Mon Feb  2 10:47:52 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Mon, 2 Feb 2004 10:47:52 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <01C3E97A.02841B80.drasnar@mineral.cz>

Nemam. Volba default_charset  je zakomentovana.

JD

> -----Původní zpráva-----
> Od:	jiri.holec na ct.cz [SMTP:jiri.holec na ct.cz]
> 
> Zdravim,
> 
> Co takhle podivat se na nastaveni php, nemas nahodou v php.ini nastavenou 
> polozku default_charset na iso-8859-?.
> 
> Jirka
> > 
> > 
> > Zdravim,
> > 
> > Potrebuji radu. Na RH9 mam db v kodovani 8859-2. Potrebuji 
> > jeji vystup 
> > dostat do prostredi phprs (www - red.systemu od J.Lukase), 
> > ktery pouziva 
> > kodovani windows-1250. Zkousel jsem nastavit spravny format takhlke:
> > 
> > Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> > 
> > Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou stale spatne. 
> > Poradite?
> > 
> > Diky.
> > 
> > Jirka Drasnar


From zakkr na zf.jcu.cz  Mon Feb  2 11:18:03 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 2 Feb 2004 11:18:03 +0100
Subject: Postgresql - vystup z db ve win1250
In-Reply-To: <01C3E976.CD8BA680.drasnar@mineral.cz>
References: <01C3E976.CD8BA680.drasnar@mineral.cz>
Message-ID: <20040202101803.GA27620@zf.jcu.cz>

On Mon, Feb 02, 2004 at 10:24:54AM +0100, Jirka Drašnar wrote:
> Zdravim,
> 
> Potrebuji radu. Na RH9 mam db v kodovani 8859-2. Potrebuji jeji vystup 
> dostat do prostredi phprs (www - red.systemu od J.Lukase), ktery pouziva 
> kodovani windows-1250. Zkousel jsem nastavit spravny format takhlke:
> 
> Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> 
> Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou stale spatne. 
> Poradite?

 Deje se tak i treba v psql klientu, tedy mimo to PHP? Neni duvodu,
 aby to nechodilo.

    Karel
    
-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/


________ Information from NOD32 ________
This message was checked by NOD32 Antivirus System for Linux Mail Server.
http://www.nod32.com

From drasnar na mineral.cz  Mon Feb  2 11:43:00 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Mon, 2 Feb 2004 11:43:00 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <01C3E981.B66F3420.drasnar@mineral.cz>

Pokud tim psql klientem myslite linuxovou konzoli tak ani tam.

Jirka

> 
> On Mon, Feb 02, 2004 at 10:24:54AM +0100, Jirka Drašnar wrote:
> > Zdravim,
> > 
> > Potrebuji radu. Na RH9 mam db v kodovani 8859-2. Potrebuji jeji vystup 
> > dostat do prostredi phprs (www - red.systemu od J.Lukase), ktery pouziva 
> > kodovani windows-1250. Zkousel jsem nastavit spravny format takhlke:
> > 
> > Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> > 
> > Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou stale spatne. 
> > Poradite?
> 
>  Deje se tak i treba v psql klientu, tedy mimo to PHP? Neni duvodu,
>  aby to nechodilo.
> 
>     Karel
>     
> -- 
>  Karel Zak  <zakkr na zf.jcu.cz>
> 

From jiri.holec na ct.cz  Mon Feb  2 12:20:09 2004
From: jiri.holec na ct.cz (jiri.holec na ct.cz)
Date: Mon, 2 Feb 2004 12:20:09 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <H0000faa10c1367e.1075720808.oma.apl.ct.cz@MHS>

Ta konzole by musela byt ve win1250 (napr. ta co je v Gnome jde prepnout)

> 
> 
> Pokud tim psql klientem myslite linuxovou konzoli tak ani tam.
> 
> Jirka
> 
> > 
> > On Mon, Feb 02, 2004 at 10:24:54AM +0100, Jirka Drašnar wrote:
> > > Zdravim,
> > > 
> > > Potrebuji radu. Na RH9 mam db v kodovani 8859-2. 
> Potrebuji jeji vystup 
> > > dostat do prostredi phprs (www - red.systemu od 
> J.Lukase), ktery pouziva 
> > > kodovani windows-1250. Zkousel jsem nastavit spravny 
> format takhlke:
> > > 
> > > Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> > > 
> > > Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou 
> stale spatne. 
> > > Poradite?
> > 
> >  Deje se tak i treba v psql klientu, tedy mimo to PHP? Neni duvodu,
> >  aby to nechodilo.
> > 
> >     Karel
> >     
> > -- 
> >  Karel Zak  <zakkr na zf.jcu.cz>
> >
> 


From drasnar na mineral.cz  Mon Feb  2 13:58:10 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Mon, 2 Feb 2004 13:58:10 +0100
Subject: Postgresql - vystup z db ve win1250
Message-ID: <01C3E994.98407AA0.drasnar@mineral.cz>

Pouzivam terminal putty, ten jde take prepnout. Kdyz ho prepnu na 
windows1250 tak jsou znaky zobrazovany spravne bez ohledu na to co nastavim 
prikazem SET CLIENT_ENCODING 'neco'.

Jirka

> > > Zdravim,
> > >
> > > Potrebuji radu. Na RH9 mam db v kodovani 8859-2.
> Potrebuji jeji vystup
> > > dostat do prostredi phprs (www - red.systemu od
> J.Lukase), ktery pouziva
> > > kodovani windows-1250. Zkousel jsem nastavit spravny
> format takhlke:
> > >
> > > Pg_Exec($spojeni,"SET CLIENT_ENCODING TO WIN1250");
> > >
> > > Bohuzel, nic se nezmenilo a znaky s a z s hackem jsou
> stale spatne.
> > > Poradite?
> >
> >  Deje se tak i treba v psql klientu, tedy mimo to PHP? Neni duvodu,
> >  aby to nechodilo.
> >
> >     Karel
 

From ukmitigation na uk.tk  Tue Feb  3 03:30:56 2004
From: ukmitigation na uk.tk (Linux_anuncio)
Date: Mon, 02 Feb 2004 23:30:56 -0300
Subject: sukper viagrma
Message-ID: <gonwubjic.2346153620afapnfbgo@Linux_anunciorvmbbcmh>

It`s fabuklous!

I took the only one pijll of Cialjs and that was such a GREAT weekend!
All the girls at the party were just punch-drunk with my potential

I have fhcked all of them THREE times but my dhck WAS able to do some more!

Cbalis- it`s COOL!!! The best weekend stuff I've ever trhied!
Haven`t you tried yet?

DO IT NkOW at 
http://www.vow-meds.com/sv/index.php?pid=genviag

irateness blackly Swansea casuals decibel entrenched flatulent maneuvers stables.
 



From gabriel.benton_tf na admmail.uwaterloo.ca  Tue Feb  3 04:48:26 2004
From: gabriel.benton_tf na admmail.uwaterloo.ca (Gabriel I. Benton)
Date: Tue, 03 Feb 2004 03:48:26 +0000
Subject: how are you
Message-ID: <HAFHJHNPAPNPNFFCFNAIODEGDFAB.gabriel.benton_tf@admmail.uwaterloo.ca>

hi,

Feel younger and stonger and last longer, let me show you how.

<a href="http://nxp.rty22.us/hgh/?hpsales">show you now ucw</a></font>

http://svb.rty22.us/hgh/?hpsales


<a href="http://kau.rty22.us/hgh/o.html">stop offerz</a>

iux ewf qno
jrm zds qcs
yos

From drasnar na mineral.cz  Tue Feb  3 09:33:53 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Ji=F8=ED_Dra=B9nar?=)
Date: Tue, 3 Feb 2004 09:33:53 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
Message-ID: <01C3EA38.D6F73820.drasnar@mineral.cz>

Db nebyla zalozena s nastavenim kodovani. Po je jejim novem zalozeni WITH 
ENCODING = 'LATIN2' je vse tak jak ma byt a kodovani je mozne prepinat. 
Dekuji vsem kteri se mi snazili poradit.
JD


From janousek na fonet.cz  Tue Feb  3 09:36:54 2004
From: janousek na fonet.cz (=?iso-8859-2?Q?Pavel_Janou=B9ek?=)
Date: Tue, 3 Feb 2004 09:36:54 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
Message-ID: <4F23E9745D562F4D90373B9C5CEF44302300FD@percival.fonet.cz>

> -----Original Message-----
> From: Jiří Drašnar [mailto:drasnar na mineral.cz] 
> Db nebyla zalozena s nastavenim kodovani. Po je jejim novem 

	To je pitomost, tedy aspon kam moje pamet saha ma kazda databaze nastaveno kodovani - bud stejne jako defaultni pro cely datastor (initdb) nebo pri vytvoreni konkretni databaze via with encoding...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------

From zakkr na zf.jcu.cz  Tue Feb  3 09:57:56 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Tue, 3 Feb 2004 09:57:56 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF44302300FD@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF44302300FD@percival.fonet.cz>
Message-ID: <20040203085756.GA13238@zf.jcu.cz>

On Tue, Feb 03, 2004 at 09:36:54AM +0100, Pavel Janoušek wrote:
> > -----Original         Message-----        From: Jiří         Drašnar
> > [mailto:drasnar na mineral.cz]   Db   nebyla  zalozena   s   nastavenim
> > kodovani. Po je jejim novem
>
>  To je  pitomost, tedy  aspon kam  moje pamet  saha ma  kazda databaze
>  nastaveno  kodovani -  bud stejne  jako defaultni  pro cely  datastor
>  (initdb) nebo pri vytvoreni konkretni databaze via with encoding...

 Dotycny  chtel  rict, ze  mela  treba  (defaultni) SQL_ASCII  do  cehoz
 "prilis  zlutouckeho  kone"  neustajis  a   pokud  ano  tak  jiz  nikdy
 nedostanes ven tak nejak celeho.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From drasnar na mineral.cz  Tue Feb  3 10:01:20 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Ji=F8=ED_Dra=B9nar?=)
Date: Tue, 3 Feb 2004 10:01:20 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
Message-ID: <01C3EA3C.AC8F0FA0.drasnar@mineral.cz>

Nainstaloval jsem linux a naimportoval data ze souboru v 8859-2. Neprovedl 
jsem pred tim initdb. Muze to byt tim?

JD

> 	To je pitomost, tedy aspon kam moje pamet saha ma kazda databaze 
nastaveno kodovani - bud stejne jako defaultni pro cely datastor (initdb) 
nebo pri vytvoreni konkretni databaze via with encoding...
>
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------

From Janousek na FoNet.Cz  Tue Feb  3 10:21:15 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Tue, 3 Feb 2004 10:21:15 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
In-Reply-To: <01C3EA3C.AC8F0FA0.drasnar@mineral.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF44301789AC@percival.fonet.cz>

> -----Original Message-----
> From: Jiří Drašnar [mailto:drasnar na mineral.cz] 
> Nainstaloval jsem linux a naimportoval data ze souboru v 
> 8859-2. Neprovedl 
> jsem pred tim initdb. Muze to byt tim?

	Pokud mate slusnou "distribuci" PostgreSQL a spoustel jste
server via /etc/rc.d/init.d/postgresql, tak tam uz drahnou dobu je test
na existenci vytvoreneho datastoru - pokud neexistuje, initdb se zavola
automaticky pri prvnim volani toho scriptu.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From Janousek na FoNet.Cz  Tue Feb  3 10:22:09 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Tue, 3 Feb 2004 10:22:09 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
In-Reply-To: <20040203085756.GA13238@zf.jcu.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF44301789AD@percival.fonet.cz>

> -----Original Message-----
> From: Karel Zak [mailto:zakkr na zf.jcu.cz] 
>  "prilis  zlutouckeho  kone"  neustajis  a   pokud  ano  tak  
> jiz  nikdy
>  nedostanes ven tak nejak celeho.

Proc? Myslim, ze staci pg_dump, editor, psql...:-)

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From drasnar na mineral.cz  Tue Feb  3 10:53:00 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Ji=F8=ED_Dra=B9nar?=)
Date: Tue, 3 Feb 2004 10:53:00 +0100
Subject: Postgresql - vystup z db ve win1250 - vyreseno
Message-ID: <01C3EA43.E465EFA0.drasnar@mineral.cz>

Distribuce LINUX  RH 9. Server jsem spoustel presne tak jak pisete.
	
	JD

> 
> 	Pokud mate slusnou "distribuci" PostgreSQL a spoustel jste
> server via /etc/rc.d/init.d/postgresql, tak tam uz drahnou dobu je test
> na existenci vytvoreneho datastoru - pokud neexistuje, initdb se zavola
> automaticky pri prvnim volani toho scriptu.
> 
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------

From singer na fornax.sk  Tue Feb  3 17:15:21 2004
From: singer na fornax.sk (Martin Spevak)
Date: Tue, 3 Feb 2004 17:15:21 +0100 (CET)
Subject: postgresql+win1250 + java(tomcat)
Message-ID: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>

Zdravim,
 mam jeden problem s kodovanim v DB. Udaje zapisane v db su win1250
(precitam som ich cez php a nastavil hlavicku... vsetko sa zobrazilo
spravne)

java vsak vnutorne pouziva UTF-8 (alebo unicode, alebo nieco ine...;)
Problem je, ze ked precitam udaj z databazy v diakritike, napr:

<priez> = Select priezvisko From User where id=1

vrati mi to Speva'k, ktore si java prehodi do svojho kodovania, takze
ak spravim dalsi selekt:

Select id From User where priezvisko=<priez>

vrati mi, ze nic nenasiel.
Nema niekto skusenosti s databazou a tomcatom, aby sa tieto udaje
interpretovli tak ako sa maju? (nemozem zmenit dokovanie udajov v DB,
pretoze nad nou pracuje niekolko systemov, ktore by bolo treba prerobit)

singer

---
         _____
 ___________(_)_______ _______ ______ ________
 __  ___/__  / __  __ \__  __ `/_  _ \__  ___/ _________CRAZY user_________
 _(__  ) _  /  _  / / /_  /_/ / /  __/_  /                                /
 /____/  /_/   /_/ /_/ _\__, /  \___/ /_/ singer na fornax.elf.stuba.sk     /
                       /____/             http://fornax.elf.stuba.sk/~singer
Martin Spevak				  tel.c.: 0903 233 040         /
Karloveska 6, 841 04, Bratislava, Slovensko___________________________/


From zakkr na zf.jcu.cz  Tue Feb  3 17:25:35 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Tue, 3 Feb 2004 17:25:35 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>
Message-ID: <20040203162535.GA8221@zf.jcu.cz>

On Tue, Feb 03, 2004 at 05:15:21PM +0100, Martin Spevak wrote:
> Zdravim,
>  mam jeden problem s kodovanim v DB. Udaje zapisane v db su win1250
> (precitam som ich cez php a nastavil hlavicku... vsetko sa zobrazilo
> spravne)
> 
> java vsak vnutorne pouziva UTF-8 (alebo unicode, alebo nieco ine...;)
> Problem je, ze ked precitam udaj z databazy v diakritike, napr:
> 
> <priez> = Select priezvisko From User where id=1
> 
> vrati mi to Speva'k, ktore si java prehodi do svojho kodovania, takze
> ak spravim dalsi selekt:
> 
> Select id From User where priezvisko=<priez>
> 
> vrati mi, ze nic nenasiel.
> Nema niekto skusenosti s databazou a tomcatom, aby sa tieto udaje
> interpretovli tak ako sa maju? (nemozem zmenit dokovanie udajov v DB,
> pretoze nad nou pracuje niekolko systemov, ktore by bolo treba prerobit)

 Kdyz klient pouziva UTF tak to nejak sdelte PostgreSQL a on bude data
 cekavat v UTF a i vam je vracet v UTF. viz:

    SET CLIENT_ENCODING TO 'UNICODE';

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From stehule na kix.fsv.cvut.cz  Tue Feb  3 18:00:43 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Tue, 3 Feb 2004 18:00:43 +0100 (CET)
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>
Message-ID: <Pine.LNX.4.44.0402031758300.6798-100000@kix.fsv.cvut.cz>

nastavte si pri spojeni 
SET client_encoding=UNICODE;

Pavel

On Tue, 3 Feb 2004, Martin Spevak wrote:

> Zdravim,
>  mam jeden problem s kodovanim v DB. Udaje zapisane v db su win1250
> (precitam som ich cez php a nastavil hlavicku... vsetko sa zobrazilo
> spravne)
> 
> java vsak vnutorne pouziva UTF-8 (alebo unicode, alebo nieco ine...;)
> Problem je, ze ked precitam udaj z databazy v diakritike, napr:
> 
> <priez> = Select priezvisko From User where id=1
> 
> vrati mi to Speva'k, ktore si java prehodi do svojho kodovania, takze
> ak spravim dalsi selekt:
> 
> Select id From User where priezvisko=<priez>
> 
> vrati mi, ze nic nenasiel.
> Nema niekto skusenosti s databazou a tomcatom, aby sa tieto udaje
> interpretovli tak ako sa maju? (nemozem zmenit dokovanie udajov v DB,
> pretoze nad nou pracuje niekolko systemov, ktore by bolo treba prerobit)
> 
> singer
> 
> ---
>          _____
>  ___________(_)_______ _______ ______ ________
>  __  ___/__  / __  __ \__  __ `/_  _ \__  ___/ _________CRAZY user_________
>  _(__  ) _  /  _  / / /_  /_/ / /  __/_  /                                /
>  /____/  /_/   /_/ /_/ _\__, /  \___/ /_/ singer na fornax.elf.stuba.sk     /
>                        /____/             http://fornax.elf.stuba.sk/~singer
> Martin Spevak				  tel.c.: 0903 233 040         /
> Karloveska 6, 841 04, Bratislava, Slovensko___________________________/
> 


From Ales.Zika na pel.br.ds.mfcr.cz  Wed Feb  4 07:29:59 2004
From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=)
Date: Wed, 4 Feb 2004 07:29:59 +0100 
Subject: postgresql+win1250 + java(tomcat)
Message-ID: <952EEDA52038D711AEA10002A562DC412071D2@www>

> 
>  Kdyz klient pouziva UTF tak to nejak sdelte PostgreSQL a on bude data
>  cekavat v UTF a i vam je vracet v UTF. viz:
> 
>     SET CLIENT_ENCODING TO 'UNICODE'
> 
> 
	A nemelo by tam byt spis SET CLIENT_ENCODING TO 'UTF8'? Mam dojem,
ze UNICODE a UTF je trochu rozdil, UNICODE koduje vsechny znaky do 2 bytu,
UTF spodek ASCII do jednoho bytu a vrsek do 2 az 4 bytu, takze na textech
bez narodnich znaku usetri misto.
	Ale JAVA snad pouziva plne UNICODE, tak by to snad mohlo chodit cele
rovnou v nem.


			Ales Zika
			CSE Spoje Pelhrimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz 

From jozef.chocholacek na qbizm.cz  Wed Feb  4 09:38:43 2004
From: jozef.chocholacek na qbizm.cz (Jozef Chocholacek)
Date: Wed, 04 Feb 2004 09:38:43 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk>
Message-ID: <4020AF93.1030904@qbizm.cz>

Martin Spevak wrote:
>  mam jeden problem s kodovanim v DB. Udaje zapisane v db su win1250
> (precitam som ich cez php a nastavil hlavicku... vsetko sa zobrazilo
> spravne)
> ...

   V akom kódovaní je vytvorená databáza? (Čo máte v stĺpci "Encoding", 
keď zadáte v psql príkaz "\l"?)

   Inak pre DB URI pre PostgreSQL JDBC ovládač existuje parameter 
charSet, ktorý je dobré nastaviť na kódovanie databázy, napr. 
jdbc:postgresql://localhost:5432/mojadb?charSet=LATIN2, vo vašom prípade 
teda asi Cp1250 (prípadne windows-1250, neviem, čo z toho vezme ovládač).


J.Ch.
-- 
Ing. Jozef Chocholacek                  Qbizm technologies, a.s.
hlavni analytik                         ... the art of software.
________________________________________________________________
Kralovopolska 139                          tel: +420 541 242 414
601 12 Brno, CZ      http://www.qbizm.cz   fax: +420 541 212 696


From zakkr na zf.jcu.cz  Wed Feb  4 09:52:46 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Wed, 4 Feb 2004 09:52:46 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <952EEDA52038D711AEA10002A562DC412071D2@www>
References: <952EEDA52038D711AEA10002A562DC412071D2@www>
Message-ID: <20040204085245.GB6218@zf.jcu.cz>

On Wed, Feb 04, 2004 at 07:29:59AM +0100, "Zíka Aleš, Ing." wrote:
> > 
> >  Kdyz klient pouziva UTF tak to nejak sdelte PostgreSQL a on bude data
> >  cekavat v UTF a i vam je vracet v UTF. viz:
> > 
> >     SET CLIENT_ENCODING TO 'UNICODE'
> > 
> > 
> 	A nemelo by tam byt spis SET CLIENT_ENCODING TO 'UTF8'? Mam dojem,
> ze UNICODE a UTF je trochu rozdil, UNICODE koduje vsechny znaky do 2 bytu,
> UTF spodek ASCII do jednoho bytu a vrsek do 2 az 4 bytu, takze na textech
> bez narodnich znaku usetri misto.
> 	Ale JAVA snad pouziva plne UNICODE, tak by to snad mohlo chodit cele
> rovnou v nem.

 Sam jsem to tam psal:

 { "unicode", PG_UTF8 },        /* alias for UTF-8 */
 { "utf8", PG_UTF8 },           /* UTF-8; RFC2279 */

 takze v PostgreSQL to alias.

 K tem jmenum, existuje UCS (ISO 10646) a Unicode, do rozpletavani vztahu UCS a 
 Unicodu bych  se nepoustel...  pro silne natury:

    http://www.cl.cam.ac.uk/~mgk25/unicode.html
    cast "What different encodings are there?"

 a neco malo v "man 7 utf-8"

 Unicode je standard zastresujici UTF-7, UTF-8, UTF-16, UTF-16LE,
 UTF-16BE a UTF-32.

 Takze samotne  "Unicode" je  nic, ale  vzhledem k  tomu ze  uchytilo na
 beznou praci UTF-8 (ktere je ASCII kompatibilni) tak se obavam to je de
 fakto alias.

 To co jste nazval Unicodem (na vse dva byte) je ve skutecnosti UCS-2.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From jakub.spicak na deltaes.cz  Wed Feb  4 10:56:50 2004
From: jakub.spicak na deltaes.cz (Jakub Spicak)
Date: Wed, 04 Feb 2004 10:56:50 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <4020AF93.1030904@qbizm.cz>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz>
Message-ID: <4020C1E2.3080804@deltaes.cz>

Ve veci JDBC vs. PostgreSQL jsem nekde nasel tuto informaci, ktera mi hodne 
pomohla pri praci s cestinou, treba i Vam:

You shouldn't need to pass any encoding and you certainly shouldn't pass an 
encoding that is different than the database encoding.

If the database is created with LATIN2 (verify by 'select 
getdatabaseencoding()' from psql) then the jdbc driver will automatically 
convert from/to the database encoding to/from the unicode internal 
representation java uses.

If you explicitly set an encoding different than the database is using you 
will likely have problems since then the driver will convert from/to this 
encoding instead of the encoding the database is using.


Jozef Chocholacek wrote:

> Martin Spevak wrote:
> 
>>  mam jeden problem s kodovanim v DB. Udaje zapisane v db su win1250
>> (precitam som ich cez php a nastavil hlavicku... vsetko sa zobrazilo
>> spravne)
>> ...
> 
> 
>   V akom kódovaní je vytvorená databáza? (Čo máte v stĺpci "Encoding", 
> keď zadáte v psql príkaz "\l"?)
> 
>   Inak pre DB URI pre PostgreSQL JDBC ovládač existuje parameter 
> charSet, ktorý je dobré nastaviť na kódovanie databázy, napr. 
> jdbc:postgresql://localhost:5432/mojadb?charSet=LATIN2, vo vašom prípade 
> teda asi Cp1250 (prípadne windows-1250, neviem, čo z toho vezme ovládač).
> 
> 
> J.Ch.

-- 
.......................................
.   Jakub Špičák                      .
.   DELTA E.S., s.r.o. Brno           .
.   Hvězdová 13                       .
.   Czech Republic                    .
.                                     .
.   e-mail: jakub.spicak na deltaes.cz   .
.   phone:  +420 5 4524 2603          .
.   fax:    +420 5 4524 2591          .
.   icq:    171816362                 .
.......................................

From jozef.chocholacek na qbizm.cz  Wed Feb  4 11:07:49 2004
From: jozef.chocholacek na qbizm.cz (Jozef Chocholacek)
Date: Wed, 04 Feb 2004 11:07:49 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <4020C1E2.3080804@deltaes.cz>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz> <4020C1E2.3080804@deltaes.cz>
Message-ID: <4020C475.9080209@qbizm.cz>

Jakub Spicak wrote:
> ...
> If the database is created with LATIN2 (verify by 'select 
> getdatabaseencoding()' from psql) then the jdbc driver will 
> automatically convert from/to the database encoding to/from the unicode 
> internal representation java uses.
> ...

   No, to je pekné, že to píšu, ale pravda to tak celkom nie je. Aspoň 
naša skúsenosť je taká, že bez "charSet=LATIN2" sa nám webaplikácie 
chovajú k diakritike dosť nepredvídateľne.

   Preto radšej používame databázy s nastaveným kódovaním UNICODE a 
nemáme problém (LATIN2 kódovanie majú len staršie DB, používané tzv. 
"kostlivcami").


J.Ch.
-- 
Ing. Jozef Chocholacek                  Qbizm technologies, a.s.
hlavni analytik                         ... the art of software.
________________________________________________________________
Kralovopolska 139                          tel: +420 541 242 414
601 12 Brno, CZ      http://www.qbizm.cz   fax: +420 541 212 696


From marketing na buraliste.com  Wed Feb  4 11:24:33 2004
From: marketing na buraliste.com (marketing na buraliste.com)
Date: Wed, 04 Feb 2004 18:24:33 +0800
Subject: Votre buraliste sur internet.
Message-ID: <d53301c3eb09$1526e750$9ed3abf6@mcgrparyvv>


From mkrause na iinfo.cz  Wed Feb  4 13:30:07 2004
From: mkrause na iinfo.cz (Michal Krause)
Date: Wed, 4 Feb 2004 13:30:07 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <4020C475.9080209@qbizm.cz>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz> <4020C1E2.3080804@deltaes.cz> <4020C475.9080209@qbizm.cz>
Message-ID: <20040204123005.GB3446@webhosting.iinfo.cz>

On 04/02/2004, Jozef Chocholacek wrote:

> Jakub Spicak wrote:
> >...
> >If the database is created with LATIN2 (verify by 'select 
> >getdatabaseencoding()' from psql) then the jdbc driver will 
> >automatically convert from/to the database encoding to/from the unicode 
> >internal representation java uses.
> >...
> 
>   No, to je pekné, že to píšu, ale pravda to tak celkom nie je. Aspoň 
> naša skúsenosť je taká, že bez "charSet=LATIN2" sa nám webaplikácie 
> chovajú k diakritike dosť nepredvídateľne.

Mam opacnou zkusenost. Minimalne s PostgreSQL 7.3.x a J2SDK 1.4.x
(standalone aplikace i servlety pod Tomcatem 5.0.x a Jetty) je cestina
v mem pripade naprosto bez problemu, a to obousmerne a bez jakehokoliv
nastavovani. Databaze je v LATIN2.

S pozdravem
Michal Krause
-- 
Vsetci by chceli byt van Goghmi, ale odrezat si ucho ani jeden.
                                                  J. Raz ve filmu Rabaka

From mlyxzfzfnvvkq na telekbird.com.cn  Thu Feb  5 02:34:21 2004
From: mlyxzfzfnvvkq na telekbird.com.cn (Randy Wilkinson)
Date: Wed, 04 Feb 2004 23:34:21 -0200
Subject: Groundbreaking HealthCare Technology: MYOELECTRIC PROSTHESES--Editors-owner
Message-ID: <NXSETJDVWSJOSPGIRUNKXXM@email.ro>

Editors-owner - Here is your requested report - #75450790

Stock-Market Spotlight - PDPR

HealhCare Tech Sector: PDPR - Pediatric Prosthetics Inc. Reveals Projected Earnings

Very exciting news from the HealthCare Tech Sector and its Groundbreaking Technology: MYOELECTRIC PROSTHESES

HOUSTON--(BUSINESS WIRE)--Pediatric Prosthetics Inc. (PDPR) announces that the Company is exceeding its projections for the first quarter of 2004.  Accounts Receivables are being accumulated at a faster rate than anticipated and major insurance companies are steadily authorizing treatments for clients.  The short-term and long-term projections illustrate the result of compounded earnings caused by the "annuity effect" of the required annual re-fits for growing children.

In fact, according to the Company's projections, revenues and sales will grow dramatically in the next few years.  As stated in the Company's news release, revenues in the next five years are expected to grow over 400%, and sales are projected to grow even more dramatically at or around 1000%.  Yes, that's right, one thousand percent.

See the whole news release for yourself: http://biz.yahoo.com/bw/040129/295979_1.html


THE COMPANY

Pediatric Prosthetics Inc., based in Houston, Texas, is the primary provider of prosthetic patient care specializing in the infant-pediatric market on a national scale. The Company will focus on both the physical needs of the children and the emotional support of their parents.


PDPR AND GROUNDBREAKING MYOELECTRIC TECHNOLOGY

Myoelectric upper extremity prostheses are the state of the art. In the absence of a hand or arm, the child's brain still continues sending signals to "grasp" or "open" the hand in the residual limb. Myoelectric sensors can read those signals through the skin (requiring no surgery) and with the computer chip magnify those signals many fold to actuate the tiny powerful motor to accomplish the task. 

Infants and children learn to open and close their "myo" on command in an astonishingly short period of time. Within a matter of a few days, the myo becomes almost an unconscious part of them, opening and closing with an almost unconscious thought.

The prostheses utilizing this technology are designed to be extremely life-like and non-threatening. The response to them by playmates and parents is usually "isn't that neat!"

PDPR has begun instituting some of these ground-breaking myoelectric technology research and development to see if it is equally as effective with lower extremity prosthetics as well. 


THE INDUSTRY

The national prosthetics industry is estimated at nearly $2 billion annually and is extremely fragmented. In this fragmentation, PDPR has developed a strong niche by focusing on the infant-pediatric prosthetics segment. This segment requires specialized expertise to meet the needs of these babies and their families.

PDPR is the only infant-pediatric prosthetics company focusing on the unique needs of these babies born with a limb loss.


SPECIFICS

Children ages 0 to 14 comprise 5% of the total $2 billion prosthetic market, $100 million. The vast majority of this 5% pediatric prosthetic market derives from babies born with a limb loss.

There are approximately 145,000 first time amputations each year, meaning first time fittings. Of these 145,000 first time amputations, less than 1% or approximately 1,000 babies born with a limb loss.

PDPR is the only infant-pediatric prosthetics company focusing on these unique needs.


REVENUE GROWTH

The economic cost from infancy to adulthood is anticipated to be over $200,000 for a below elbow amputee. Adults will spend an additional $200,000 on their artificial arms. Revenue growth is directly correlated with the physical growth of the children. PDPR's management model for growth combines the strength and expertise of upper and lower extremity specialists with over 50 years of combined experience.


NATIONAL EXPOSURE

The management team of PDPR is nationally recognized as the leading prosthetists in the infant-pediatric prosthetics field. PDPR's management has recently been featured in, "Orthotics & Prosthetics Business News", written up in "Life Magazine", and some of the fitted children have appeared on national TV shows, including "Good Morning America", "Maury Povich","Phil Donahue", and "20-20."


IN CONCLUSION

By targeting the infant-pediatric need, PDPR will generate a consistent revenue stream by servicing their clients from childhood to adulthood. This "annuity effect" should compound earnings year after year and enable PDPR to enjoy stable growth.








This report is based on Stock-Market Spotlight's independent analysis but also relies on information supplied by sources believed to be reliable. This report may not be the opinion of PDPR management. This report should be considered biased and contains usually only positive statements regarding the featured company. Stock-Market Spotlight does not own or will not purchase PDPR common shares in the open market. The information contained in this report shall not constitute, an offer to sell or solicitation of any offer to purchase any security. Penny stocks are considered to be highly speculative and may be unsuitable for all but very aggressive investors. It is intended for information and entertainment only. Some statements may contain so-called "forward-looking statements". Many factors could cause actual results to differ. Investors should consult with their Investment Advisor concerning PDPR. This newsletter was written and distributed for a 3000 dollar fee paid by a third party PDPR shareholder who is purported to have a large stock position in the featured company.  It is unknown to Stock-Market Spotlight whether this shareholder intends to sell any or all of his stock position in the featured company. Copyright 2004 Stock-Market Spotlight. All Rights Reserved.


0

8

7

0

0

3

0

5

3

6

4

8

9

8

7

0

6

5

7

7

castle depart systemization blackman seismography nominee laureate gentian beebe bye shrub economic defeat sharpe tree agglutinin sus babble foe crowd quixote cushman coprinus surcharge midway libido swingable marseilles trichloroacetic sleety insurrect sacrificial driven griffith pate theoretician middleman thieves madam documentary next abuse arbutus economist pervert chaotic transfusion byzantine breakfast consortium freeman character suction excerpt bitt zippy choke alight occlusive printmake avocado lesotho monocotyledon middleweight alva alpha whose savage wheezy applaud external embark oceania spinal transportation penelope afforestation pence crispin attempt possess revelry prodigious reticulum ephemerides scarlatti karma pin indices stanton haystack bundy buggy aquarium propensity scarlet clark embroil senor wartime kathy description orr tibetan rsvp checksumming bong shunt intramolecular winnow anachronism bengal borg anastomosis curlicue brandish respondent holbrook hammond charlemagne prerequisite what're conley diphtheria comprehension vella begonia millionaire dynamo mcmillan halfhearted dereference chieftain invasion blacken character piteous contentious adenoma levitt shock circumcise vacate thallophyte adsorptive flange rope kalmia motor rehearsal mend banquet expectorant blast eradicable bowfin codetermine croak perceptible winston adventurous cockpit brimful conversation geophysics consequential swordtail sic fetid barnett cemetery metalliferous allowance satiable circular cowhand perceive guanine assuage beady concert diversion prince ambrosial british mila showdown anglicanism clothbound cartographer 

From nopetr na tiscali.cz  Thu Feb  5 08:55:05 2004
From: nopetr na tiscali.cz (nopetr na tiscali.cz)
Date: Thu, 5 Feb 2004 08:55:05 +0100
Subject: Smazany postmaster v PostgreSQL
Message-ID: <3FB9681000056D3B@stateless2.tiscali.cz>

Opravneny uzivatel k postgre nedopatrenim smazal soubor postmaster. Lze
jej obnovit, aniz by doslo k  dalsimu ohrozeni provozu stavajici databaze?
Dekuji, Petr

_______________________________________________________________________

E-mailova schranka stale po ruce - kdykoliv, kdekoliv. Eurotel Vam nabizi
moznost prijimat a odesilat e-maily primo z mobilniho telefonu bez pouziti
pocitace. Ted levnejsi nez SMS! Vice na http://adsweb.tiscali.cz/eurotel.html




From Peter.Mann na tuke.sk  Thu Feb  5 09:02:56 2004
From: Peter.Mann na tuke.sk (Peter Mann)
Date: Thu, 5 Feb 2004 09:02:56 +0100
Subject: Smazany postmaster v PostgreSQL
In-Reply-To: <3FB9681000056D3B@stateless2.tiscali.cz>
References: <3FB9681000056D3B@stateless2.tiscali.cz>
Message-ID: <20040205080256.GC12850@dot.tuke.sk>

On Thu, Feb 05, 2004 at 08:55:05AM +0100, nopetr na tiscali.cz wrote:
> Opravneny uzivatel k postgre nedopatrenim smazal soubor postmaster. 

aka verzia? kde je ten subor? ja tu nic take nevidim (7.3.4)

> Lze
> jej obnovit, aniz by doslo k  dalsimu ohrozeni provozu stavajici databaze?

ano, zo zalohy ;-)))

-- 

5o   Peter.Mann at tuke.sk
     KLFMANiK ICQ 12491471
         PM2185-RIPE

From horak na sitmp.cz  Thu Feb  5 09:07:53 2004
From: horak na sitmp.cz (=?iso-8859-2?Q?Hor=E1k_Daniel?=)
Date: Thu, 5 Feb 2004 09:07:53 +0100
Subject: Smazany postmaster v PostgreSQL
Message-ID: <66EFFC1A2B0A424E87D68EC10B1F458D03DA99@EXCH2.mmp.plzen-city.cz>

> Opravneny uzivatel k postgre nedopatrenim smazal soubor 
> postmaster. Lze

Ten z bin adresare? To je jen symbolicky link na postgres, takze staci
"ln -s postgres postmaster"


			Dan

From singer na pobox.sk  Thu Feb  5 12:17:09 2004
From: singer na pobox.sk (Martin Spevak)
Date: Thu, 05 Feb 2004 12:17:09 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <4020C475.9080209@qbizm.cz>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz> <4020C1E2.3080804@deltaes.cz> <4020C475.9080209@qbizm.cz>
Message-ID: <40222635.9060605@pobox.sk>

Dakujem za vela odpovedi,
problem stale pretrvava, takze tu su dalsie moje poznatky k problemu.

najprv:
ak tam to \l
napise mi to pri databaze SQL_ASCII a v nej su udaje v kodovani win-1250,
(co asi nie je dobra kombinacia) postgres je 7.3.1

skusil som niektore veci ako:
--------------------
jdbc://..../menodb?charSet=win-1250
-> toto mi pise, ze databaza obsahuje nezname znaky pre SQL_ASCII a
skonci vsetko s vynimkou... ak nedam nic, situacia je asi taka, ze
v DB je udaj vo win kodovani, on ho precita spravne... ked ho necham 
vypisat
vsetko je ok, ale ked uz ide to DB necha tu citatelnu hodnotu,
ktora samozrejme v DB nie je.

---------------------
ak dam do query SET CLIENT_ENCODING='nieco', tak to padne, pretoze
SET nevrati riadky ako query, takze java napise, ze nepozna formu vystupu a
padne na vynimke.

Nad tou databazou pracuje niekolko php systemov (moj je na zadavanie 
projektov,
dalsi je na preberanie a revidovania... atd)
Zisil som vsak, ze SET CLIENT... pracuje v php, takze ma napadlo, prerobit
vsetky udaje do UFT8, vytvorit novu DB a cely prevedeny dump tam vlozit.
Java to potom zoberie a ked dam v php ten SET na UTF8, ide to tiez.

chcel by som sa vas opytat,  ako skusenejsich... moze mat tento postup 
nejake
problemy ktore nevidim?

dalej ako prekonvertovat win (alebo iso-8859-2) do utf8.. nasiel som 
nejaku funkciu v php
ktora to vsak zvlada iba z iso-8859-1 a su tam nejake programceky ako to 
spravit
z iso-8859-2, ale iba pre nejake jazyky.. slovencina a cestina 
samozrejme chyba ;-)

singer



From Janousek na FoNet.Cz  Thu Feb  5 12:19:28 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Thu, 5 Feb 2004 12:19:28 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <40222635.9060605@pobox.sk>
Message-ID: <4F23E9745D562F4D90373B9C5CEF44301789C7@percival.fonet.cz>

> -----Original Message-----
> From: Martin Spevak [mailto:singer na pobox.sk] 
> ak tam to \l
> napise mi to pri databaze SQL_ASCII a v nej su udaje v 
> kodovani win-1250,
> (co asi nie je dobra kombinacia) postgres je 7.3.1

	Dokud nenapravite tento zjevny nesmysl je jakakoli dalsi prace a
snaha marna... - jak jsem jiz radit - pg_dump, editor, psql...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From stehule na kix.fsv.cvut.cz  Thu Feb  5 12:44:10 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 5 Feb 2004 12:44:10 +0100 (CET)
Subject: Smazany postmaster v PostgreSQL
In-Reply-To: <3FB9681000056D3B@stateless2.tiscali.cz>
Message-ID: <Pine.LNX.4.44.0402051112520.21615-100000@kix.fsv.cvut.cz>

Pokud obnovite odpovidajici verzi, tak by se nic stat nemelo.

Pavel Stehule

On Thu, 5 Feb 2004 nopetr na tiscali.cz wrote:

> Opravneny uzivatel k postgre nedopatrenim smazal soubor postmaster. Lze
> jej obnovit, aniz by doslo k  dalsimu ohrozeni provozu stavajici databaze?
> Dekuji, Petr
> 
> _______________________________________________________________________
> 
> E-mailova schranka stale po ruce - kdykoliv, kdekoliv. Eurotel Vam nabizi
> moznost prijimat a odesilat e-maily primo z mobilniho telefonu bez pouziti
> pocitace. Ted levnejsi nez SMS! Vice na http://adsweb.tiscali.cz/eurotel.html
> 
> 
> 


From zakkr na zf.jcu.cz  Thu Feb  5 12:45:34 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 5 Feb 2004 12:45:34 +0100
Subject: postgresql+win1250 + java(tomcat)
In-Reply-To: <40222635.9060605@pobox.sk>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz> <4020C1E2.3080804@deltaes.cz> <4020C475.9080209@qbizm.cz> <40222635.9060605@pobox.sk>
Message-ID: <20040205114534.GC12289@zf.jcu.cz>

On Thu, Feb 05, 2004 at 12:17:09PM +0100, Martin Spevak wrote:

> najprv:
> ak tam to \l
> napise mi to pri databaze SQL_ASCII a v nej su udaje v kodovani win-1250,
> (co asi nie je dobra kombinacia) postgres je 7.3.1

 Ja myslim, ze je vam jasne, ze prave v tomdle je problem. Jsou kodovani
 mezi kteryma  lze (a  PostgreSQL to  umi) prekodovavat. ASCII  je ovsem
 konecna stanice a zadne kodovani do/z se nekona.

> vsetky udaje do UFT8, vytvorit novu DB a cely prevedeny dump tam vlozit.
> Java to potom zoberie a ked dam v php ten SET na UTF8, ide to tiez.

 Ano  to  muze  byt  cesta. Dokonce   v  pripade  toho  Java  klienta  i
 efektivnejsi protoze nic se neprekodovava.

> chcel by som sa vas opytat,  ako skusenejsich... moze mat tento postup 
> nejake
> problemy ktore nevidim?
> 
> dalej ako prekonvertovat win (alebo iso-8859-2) do utf8.. nasiel som 
> nejaku funkciu v php
> ktora to vsak zvlada iba z iso-8859-1 a su tam nejake programceky ako to 
> spravit

 Pokud myslite prekodovani toho dumpu  tak muzete pouzit program "iconv"
 ktery zvlada vsechny myslitelne i nemyslitelne kodovani.

 Ovsem pokud  ten dump  mate v  CP1250 tak  ani nemusite  to prekodovani
 delat, staci kdyz PostgreSQL reknete, ze takove kodovani klient pouziva
 a PostgreSQL si to prekodovani z CP1250 na UFT8 udela sam.

 export PGCLIENTENCODING='CP1250'
 psql mojedb_v_ufg8 -f dump_v_1250

 Jinak: http://www.root.cz/clanek/1027

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From singer na pobox.sk  Thu Feb  5 20:12:32 2004
From: singer na pobox.sk (Martin Spevak)
Date: Thu, 05 Feb 2004 20:12:32 +0100
Subject: postgresql+win1250 + java(tomcat) - vyriesene
In-Reply-To: <20040205114534.GC12289@zf.jcu.cz>
References: <Pine.LNX.4.44.0402031707010.31781-100000@fornax.elf.stuba.sk> <4020AF93.1030904@qbizm.cz> <4020C1E2.3080804@deltaes.cz> <4020C475.9080209@qbizm.cz> <40222635.9060605@pobox.sk> <20040205114534.GC12289@zf.jcu.cz>
Message-ID: <402295A0.7010909@pobox.sk>

dakujem za vsetky rady, nakoniec som to prekonvertoval a zda sa, ze 
vsetko bezi ako ma..

> export PGCLIENTENCODING='CP1250'
> psql mojedb_v_ufg8 -f dump_v_1250
>
> Jinak: http://www.root.cz/clanek/1027
>
>    Karel
>



From vino.e-export na email.it  Mon Feb  9 17:40:51 2004
From: vino.e-export na email.it (WINE FROM ITALY)
Date: Mon, 9 Feb 2004 17:40:51 +0100
Subject: WINE FROM ITALY
Message-ID: <200402091641.i19Gf4RZ002577@anor.ics.muni.cz>

Dear Sirs,

We are interested in cooperation with importers, distributors of quality
wine worldwide.

Our production, based in city of Naples-Italy, is for sure one of the most famous
in this part of Europe,with the best quality of sorted wine as well as the lowest
pricing fo sure.

Please visit our web site at www.vinicolalamura.it and check by your self.
If than you will still be interested please contact the undersigned at any time.

Sincerely yours,

"E & E" 
Naples-Italy
vino.e-export na email.it
tel. ++ 39 (081) 871 8457
fax. ++ 39 (081) 394 4218

Attn. Luigi Coppola
Marketing Director

From konf na chalu.cz  Tue Feb 10 19:07:45 2004
From: konf na chalu.cz (konf na chalu.cz)
Date: Tue, 10 Feb 2004 19:07:45 +0100
Subject: test
Message-ID: <1076436465.40291df1bd706@webmail.move.cz>



Pardon ...

From VQIGCTJ na realeds.com  Wed Feb 11 08:42:36 2004
From: VQIGCTJ na realeds.com (Augustine Fitzgerald)
Date: Wed, 11 Feb 2004 08:42:36 +0100
Subject: 60-% off Generic Vi@ gra, a l-i-m-i-t-e-d time only
Message-ID: <GZHHTNPCOOAIZDSUVPQCZL@realeds.com>

scandinavia thirteenth shown
'G*e*n*e*r*i*c*** vi_ na gr@' 70% Less than v(i)agra ,the lowest prices you will find on the Internet!

Gene'ric vi_agra is exactly the same as the brand name via*gra, both contain the same active ingredient Sildenafil Citrate, however buying G.E.N.ER.I.C drugs will cost you a fraction of the cost.

- To have firmer erect`ion
- Enjoy s^ex life better
- Fulfil partner's se|xu na l needs
- Bolster self confidence
- Renew and strengthen (s)ex life    
- Restore intimacy
- Solidify s\exual bonds 

More Information Goto out site
http://www.realeds.com/xm/
 


counterargument advocate choice goldman blimp defocus microjoule chive terminal tweeze adagio shanghai blueberry percent agglutinin loin behest progressive uppercut appeal populism citrus egress apartheid appendage balinese inconsolable halo pottery parasitic cabbage newt jalopy meltwater glamor jacobi servitor perihelion dicotyledon 


From drasnar na mineral.cz  Wed Feb 11 13:40:31 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Ji=F8=ED_Dra=B9nar?=)
Date: Wed, 11 Feb 2004 13:40:31 +0100
Subject: postgresql - problem s casem 
Message-ID: <01C3F0A4.9EB6F8C0.drasnar@mineral.cz>

Zdravim,

mam problem:

prenesl db jsem z RH 6.xx na RH 9. Nedari se me rozchodit nasledujici select, ktery na te starsi verzi fungoval. V cem by mohl byt problem?

$vysledek = pg_Exec($database, "SELECT id, poznamka, date_part('epoch',zarazeno::datetime) as vt FROM odkazy");

do prohlizece se mi vraci:

Warning: pg_exec() query failed: ERROR: Type "datetime" does not exist 


 Diky za pripadnou radu. Jirka

 drasnar na mineral.cz  mailto:drasnar na mineral.cz  http://www.mineral.cz


From stehule na kix.fsv.cvut.cz  Wed Feb 11 14:07:54 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Wed, 11 Feb 2004 14:07:54 +0100 (CET)
Subject: postgresql - problem s casem 
In-Reply-To: <01C3F0A4.9EB6F8C0.drasnar@mineral.cz>
Message-ID: <Pine.LNX.4.44.0402111406520.27123-100000@kix.fsv.cvut.cz>

Protoze typ datetime byl tusim zrusen cca ve verzi 7.0. Pouzivejte misto 
toho tyo timestamp.

zdravim
Pavel Stehule

On Wed, 11 Feb 2004, Jiří Drašnar wrote:

> Zdravim,
> 
> mam problem:
> 
> prenesl db jsem z RH 6.xx na RH 9. Nedari se me rozchodit nasledujici select, ktery na te starsi verzi fungoval. V cem by mohl byt problem?
> 
> $vysledek = pg_Exec($database, "SELECT id, poznamka, date_part('epoch',zarazeno::datetime) as vt FROM odkazy");
> 
> do prohlizece se mi vraci:
> 
> Warning: pg_exec() query failed: ERROR: Type "datetime" does not exist 
> 
> 
>  Diky za pripadnou radu. Jirka
> 
>  drasnar na mineral.cz  mailto:drasnar na mineral.cz  http://www.mineral.cz
> 


From eemhywajwbwvm na valsee.com  Thu Feb 12 00:41:21 2004
From: eemhywajwbwvm na valsee.com (Andrea Marsh)
Date: Thu, 12 Feb 2004 00:41:21 +0100
Subject: Mak.e y o u look and f.e.e.l 20 years Younge r
Message-ID: <LNQLPAETMIDGMEKISFKJRQJX@valsee.com>

L.o.se w.e(i)ght while building lean muscle mass and r.eversing the ravages of a.ging all at once.


Remarkable discoveries about H.uman G.rowth H.ormones (H)(G)(H) 
are changing the way we think about a.ging and w.eigh.t l.o.s.s.

1.Body F.at Loss 82% i.mprovement.
2.Wrinkle Reduction 61% impro.vement. 
3.Energy Level 84% improvem.ent. 
4.Muscle Strength 88% improv.ement. 
5.S.exual Potency 75% impro.vement. 
6.Emotional Stability 67% impr.ovement. 
7.Memory 62% imp.rovement.

Visit Our Web Site and Learn The Facts
http://www.valsee.com/we/



G'et o.ff the l-i.s't
http://www.valsee.com/b.html

suggestive virus confiscate optoelectronic decry camelback monel press valery watchman awry spleenwort dingo munificent federal mort narbonne coca gage dictatorial luxuriant clone fizeau gown snigger fatty scription caller transcribe disastrous yearbook bitt botulism acknowledge assert schoolgirl crime bodhisattva across peacemake  waffle clapboard cantonese herman benight dixie commonweal dialogue group efficient decennial sylow copperfield concurrent bessel massif temple regulate resistor paean unison polity wac jordan spice twilight rafael porridge shutoff 


From Ales.Zika na pel.br.ds.mfcr.cz  Thu Feb 12 09:46:12 2004
From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=)
Date: Thu, 12 Feb 2004 09:46:12 +0100
Subject: Ceske razeni v PgSQL
Message-ID: <A458B72B045BD811959B0002A562DC41A1A4@fupelnt2.pel.br.ds.mfcr.cz>

	Zdravim,

	mame u poskytovatele webu databazi PgSQL 7.3.4 a asi ma spatne
nastavene locales, protoze ORDER BY spatne radi ceska pismena.
	Da se to nejak obejit, teba nejakou funkci, ktera to prekouse do
ASCII tak, ze to bude radit dobre? Je neco takoveho standardne v Postgresu?


	Diky,

			Ales Zika
			CSE Spoje Pelhrimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz 

From zakkr na zf.jcu.cz  Thu Feb 12 09:52:58 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 12 Feb 2004 09:52:58 +0100
Subject: Ceske razeni v PgSQL
In-Reply-To: <A458B72B045BD811959B0002A562DC41A1A4@fupelnt2.pel.br.ds.mfcr.cz>
References: <A458B72B045BD811959B0002A562DC41A1A4@fupelnt2.pel.br.ds.mfcr.cz>
Message-ID: <20040212085257.GB29932@zf.jcu.cz>

On Thu, Feb 12, 2004 at 09:46:12AM +0100, "Zíka Aleš, Ing." wrote:
> 	Zdravim,
> 
> 	mame u poskytovatele webu databazi PgSQL 7.3.4 a asi ma spatne
> nastavene locales, protoze ORDER BY spatne radi ceska pismena.
> 	Da se to nejak obejit, teba nejakou funkci, ktera to prekouse do
> ASCII tak, ze to bude radit dobre? Je neco takoveho standardne v Postgresu?

 No je reseni na ...., ale  kdo chce kam pomocme mu tam. Pokud pouzivate
 CP1250 nebo Latin2 tak muzete zkusit to_ascii(),

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From stehule na kix.fsv.cvut.cz  Thu Feb 12 09:56:11 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 12 Feb 2004 09:56:11 +0100 (CET)
Subject: Ceske razeni v PgSQL
In-Reply-To: <A458B72B045BD811959B0002A562DC41A1A4@fupelnt2.pel.br.ds.mfcr.cz>
Message-ID: <Pine.LNX.4.44.0402120950550.2247-100000@kix.fsv.cvut.cz>

pokud to prekousete do ascii, tak Vam to cesky radit nebude, ledazebyste 
si napsal funkci, ktera by nahrazovala ch na hz, atd, a to mi prijde dost 
hrozny reseni. U postgresu doporucuji podivat se z jakym locales byla 
vygenerovana tmplate0, resp. jake locales ma uzivatel postgres, kdyz 
spoustite initdb

Pavel Stehule

On Thu, 12 Feb 2004, "Zíka Aleš, Ing." wrote:

> 	Zdravim,
> 
> 	mame u poskytovatele webu databazi PgSQL 7.3.4 a asi ma spatne
> nastavene locales, protoze ORDER BY spatne radi ceska pismena.
> 	Da se to nejak obejit, teba nejakou funkci, ktera to prekouse do
> ASCII tak, ze to bude radit dobre? Je neco takoveho standardne v Postgresu?
> 
> 
> 	Diky,
> 
> 			Ales Zika
> 			CSE Spoje Pelhrimov
> 
> 			http://results.cz
> 			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
> 				  Ales.Zika na seznam.cz 
> 


From Ales.Zika na pel.br.ds.mfcr.cz  Thu Feb 12 10:24:15 2004
From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=)
Date: Thu, 12 Feb 2004 10:24:15 +0100
Subject: Ceske razeni v PgSQL
Message-ID: <A458B72B045BD811959B0002A562DC41A1B9@fupelnt2.pel.br.ds.mfcr.cz>

> pokud to prekousete do ascii, tak Vam to cesky radit nebude, 
> ledazebyste 
> si napsal funkci, ktera by nahrazovala ch na hz, atd, a to mi 
> prijde dost 
> hrozny reseni.

 	No takhle nejak jsem to myslel, ne primo do ASCII, ale ve stylu
A->A, B->B, C->C, C s hackem->D, D->E, hrozny to nepochybne je :-(


 U postgresu doporucuji podivat se z jakym locales byla 
> vygenerovana tmplate0, resp. jake locales ma uzivatel postgres, kdyz 
> spoustite initdb
> 
	Jak to zjistim, ja k tomu nemam pristup, me pusti jen na moji
databazi pod mym uzivatelem?


			Ales Zika
			CSE Spoje Pelhrimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz 

From drasnar na mineral.cz  Thu Feb 12 10:27:20 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Thu, 12 Feb 2004 10:27:20 +0100
Subject: postgresql - problem s casem 
Message-ID: <01C3F152.CC978440.drasnar@mineral.cz>

Zdravim,

dekuji za pomoc p. Stehulovi. Vyber SELECT 
date_part('epoch',zarazeno::date) from odkazy as vt; uz funguje a z radky 
vypisuje prislusne hodnoty. Ma to jeste jednu vadu na krase: neplni se vt. 
Pokud pouziji select v php tak stale nefunguje a nadava ze vt neexistuje 
...

$vt =pg_result($vysledek, $i, "vt");
Warning: pg_result() bad column offset specified

Poradite? Diky Jirka

>prenesl db jsem z RH 6.xx na RH 9. Nedari se me rozchodit nasledujici 
select, ktery na te starsi verzi fungoval. V cem by mohl byt problem?
>$vysledek = pg_Exec($database, "SELECT id, poznamka, 
date_part('epoch',zarazeno::datetime) as vt FROM odkazy");
>do prohlizece se mi vraci:
>Warning: pg_exec() query failed: ERROR: Type "datetime" does not exist



From stehule na kix.fsv.cvut.cz  Thu Feb 12 10:44:53 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 12 Feb 2004 10:44:53 +0100 (CET)
Subject: Ceske razeni v PgSQL
In-Reply-To: <A458B72B045BD811959B0002A562DC41A1B9@fupelnt2.pel.br.ds.mfcr.cz>
Message-ID: <Pine.LNX.4.44.0402121034570.2247-100000@kix.fsv.cvut.cz>

Zvednu telefon :->? Teoreticky 

pg_controldata /usr/local/pgsql/data

Číslo verze pg_controlu:            72
Číslo verze katalogu:               200402021
Status seskupení databáze:               v provozu
Poslední modifikace pg_controlu:             
Čt 12. únor 2004, 08:15:45 CET
ID současného log souboru:                  1
Následující segment log souboru:                51
Poslední umístění kontrolního bodu:           1/32373C94
Předešlé umístění kontrolního bodu:            1/32373C54
Poslednější umístění REDO kontrolního bodu:    1/32373C94
Poslední umístění UNDO kontrolního bodu:    0/0
Poslední umístění StartUpID kontrolního bodu:        29
Poslední umístění NextXID kontrolního bodu:          10130
Poslední umístění NextOID kontrolního bodu:          8719266
Čas posledního kontrolního bodu:            Čt 12. únor 2004, 08:15:42 CET
Velikost databázového bloku:                  8192
Bloků v segmentu velké relace: 131072
Maximální délka identifikátorů:        64
Maximální počet argumentů funkcí: 32
Způsob uložení typu date/time:               floating-point numbers
Maximální délka jména locale:        128
LC_COLLATE (porovnávání řetězců):                           cs_CZ.latin2
LC_CTYPE (typy znaků):                             cs_CZ.latin2


jenomze k tomu musite mit roota nebo postgres. Mam nainstalovanou 7.5, 
takze netusim jestli nasledujici dotaz zafunguje na 7.3. U mne lze 

intra=# SELECT name, setting from pg_settings where name like 'lc%';
    name     |   setting
-------------+--------------
 lc_collate  | cs_CZ.latin2
 lc_ctype    | cs_CZ.latin2
 lc_messages | cs_CZ.latin2
 lc_monetary | cs_CZ.latin2
 lc_numeric  | cs_CZ.latin2
 lc_time     | cs_CZ.latin2
(6 řádek)


Pavel Stehule

On Thu, 12 Feb 2004, "Zíka Aleš, Ing." wrote:

> > pokud to prekousete do ascii, tak Vam to cesky radit nebude, 
> > ledazebyste 
> > si napsal funkci, ktera by nahrazovala ch na hz, atd, a to mi 
> > prijde dost 
> > hrozny reseni.
> 
>  	No takhle nejak jsem to myslel, ne primo do ASCII, ale ve stylu
> A->A, B->B, C->C, C s hackem->D, D->E, hrozny to nepochybne je :-(
> 
> 
>  U postgresu doporucuji podivat se z jakym locales byla 
> > vygenerovana tmplate0, resp. jake locales ma uzivatel postgres, kdyz 
> > spoustite initdb
> > 
> 	Jak to zjistim, ja k tomu nemam pristup, me pusti jen na moji
> databazi pod mym uzivatelem?
> 
> 
> 			Ales Zika
> 			CSE Spoje Pelhrimov
> 
> 			http://results.cz
> 			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
> 				  Ales.Zika na seznam.cz 
> 


From stehule na kix.fsv.cvut.cz  Thu Feb 12 10:50:26 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 12 Feb 2004 10:50:26 +0100 (CET)
Subject: postgresql - problem s casem 
In-Reply-To: <01C3F152.CC978440.drasnar@mineral.cz>
Message-ID: <Pine.LNX.4.44.0402121045480.2247-100000@kix.fsv.cvut.cz>

On Thu, 12 Feb 2004, Jirka Drašnar wrote:

> Zdravim,
> 
> dekuji za pomoc p. Stehulovi. Vyber SELECT 
> date_part('epoch',zarazeno::date) from odkazy as vt; uz funguje a z radky 
> vypisuje prislusne hodnoty. Ma to jeste jednu vadu na krase: neplni se vt. 
> Pokud pouziji select v php tak stale nefunguje a nadava ze vt neexistuje 
> ...
> 
> $vt =pg_result($vysledek, $i, "vt");
> Warning: pg_result() bad column offset specified

Co pouzivate za rozhrani? Jinak alias vt davate na tabulku. To jste mel na 
mysli? V puvodni verzi jste jej mel za sloupcem :->


> 
> Poradite? Diky Jirka
> 
> >prenesl db jsem z RH 6.xx na RH 9. Nedari se me rozchodit nasledujici 
> select, ktery na te starsi verzi fungoval. V cem by mohl byt problem?
> >$vysledek = pg_Exec($database, "SELECT id, poznamka, 
> date_part('epoch',zarazeno::datetime) as vt FROM odkazy");
> >do prohlizece se mi vraci:
> >Warning: pg_exec() query failed: ERROR: Type "datetime" does not exist
> 
> 


From zakkr na zf.jcu.cz  Thu Feb 12 10:51:34 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 12 Feb 2004 10:51:34 +0100
Subject: postgresql - problem s casem
In-Reply-To: <01C3F152.CC978440.drasnar@mineral.cz>
References: <01C3F152.CC978440.drasnar@mineral.cz>
Message-ID: <20040212095134.GD29932@zf.jcu.cz>

On Thu, Feb 12, 2004 at 10:27:20AM +0100, Jirka Drašnar wrote:
> Zdravim,
> 
> dekuji za pomoc p. Stehulovi. Vyber SELECT 
> date_part('epoch',zarazeno::date) from odkazy as vt; uz funguje a z radky 
> vypisuje prislusne hodnoty. Ma to jeste jednu vadu na krase: neplni se vt. 
> Pokud pouziji select v php tak stale nefunguje a nadava ze vt neexistuje 
> ..
> 
> $vt =pg_result($vysledek, $i, "vt");
> Warning: pg_result() bad column offset specified

 Moc to nechapu, ale rekl bych, ze tam vidim dve chyby:

 1/ SELECT date_part('epoch',zarazeno::date) FROM odkazy AS vt;
    .. to "AS" je alias pro jmeno tabulky takze ne sloupec.

    to by bylo:

    SELECT date_part('epoch',zarazeno::date) AS vt FROM odkazy;

 2/ pokud mam ve sve mlhave pameti o PHP tak pg_result() bere
    cisla radek/sloupcu. Ostatne ten warning to i rika.

    $vt =pg_result($vysledek, $i, 0);

> Poradite? Diky Jirka

    A vy na oplatku prectete manul PHP/PostgreSQL :-)

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From drasnar na mineral.cz  Thu Feb 12 10:59:29 2004
From: drasnar na mineral.cz (=?ISO-8859-2?Q?Jirka_Dra=B9nar?=)
Date: Thu, 12 Feb 2004 10:59:29 +0100
Subject: postgresql - problem s casem 
Message-ID: <01C3F157.4A421780.drasnar@mineral.cz>

Upsla jsem se :-( , spravne ma byt

SELECT date_part('epoch',zarazeno::date) as vt FROM odkazy;

Jirka

From zovqfp na eqmeds.com  Thu Feb 12 14:39:03 2004
From: zovqfp na eqmeds.com (Estela Thacker)
Date: Thu, 12 Feb 2004 14:39:03 +0100
Subject: Save 60% with V.I.A.G.R.A
Message-ID: <FLNYVBWDXXWUVGNCODCILQISQ@askcare.com>

Wow Databases, this is awesome.  I never thought i could save so much on my Viagra purchases.  Apparent GSC, a generic version of viagra is the same exact thing, but more than 60% less.

I found this to be so awesome im telling everyone, i think you should check it out.  Thier site is:

http://order.askcare.com/host/default.asp?id=1912

Let me know what you think!



R e m o v e|| http://order.askcare.com/host/emailremove.asp






From otakarek na post.cz  Thu Feb 12 15:31:59 2004
From: otakarek na post.cz (otakarek na post.cz)
Date: Thu, 12 Feb 2004 15:31:59 +0100 (CET)
Subject: Postgresql 7.3/contrib/ltree - jak na "rekurzivni" trigger?
Message-ID: <bd99307768cab1fc6ec3530ad6f6d8b4@www1.mail.post.cz>

Zdravim,

zacal jsem si hrat se stromy v PG v komginaci s contrib/ltree.
Vse funguje k me spokojenosti, ale mam problem s UPDATEm v
triggeru make_ltree_struct(viz priloha). Jeho funkce(UPDATE)
spociva ve zjisteni poctu vsech potomku rodice v korenu. Nejak to
nemohu rozchodit (vzdy koncim na nechtene rekurzivite tohoto
triggeru). Tak jak to mam ted to sice funguje, ale neni to ciste.
Navic mi to pri zadani SQL: UPDATE test_ltree set
_timestamp=CURRENT_TIMESTAMP;
Vyhodi nasledujici chybu:
ERROR:  heap_mark4update: (am)invalid tid
Pokud z triggeru odstranim ten nestastny UPDATE, tak chyba
nenaskakuje. Jak na to? Diky za radu.
--
Otas

-- 
Chces kilo? Tak pripoj kamose pres VOLNY.
Vice na http://studentpartner.volny.cz/

From otakarek na post.cz  Thu Feb 12 15:36:45 2004
From: otakarek na post.cz (otakarek na post.cz)
Date: Thu, 12 Feb 2004 15:36:45 +0100 (CET)
Subject: Fwd: Postgresql 7.3/contrib/ltree - jak na "rekurzivni" trigger?
Message-ID: <d7b4369ded5c84ac4e80e9d56aa431e1@www2.mail.post.cz>

Omluva za tu prilohu.
Volny ma potiz s prilohami :-/
--
Otas

-- 
Chces kilo? Tak pripoj kamose pres VOLNY.
Vice na http://studentpartner.volny.cz/
------------- další část ---------------
An embedded message was scrubbed...
From: otakarek na post.cz
Subject: Postgresql 7.3/contrib/ltree - jak na "rekurzivni" trigger?
Date: Thu, 12 Feb 2004 15:31:59 +0100 (CET)
Size: 4911
URL: <http://www.linux.cz/pipermail/test/attachments/20040212/af25134f/attachment.mht>

From vaclav.ovsik na i.cz  Fri Feb 13 11:42:34 2004
From: vaclav.ovsik na i.cz (=?iso-8859-2?Q?V=E1clav_Ovs=EDk?=)
Date: Fri, 13 Feb 2004 11:42:34 +0100
Subject: PostgreSQL + DBD::Pg - jak zakazat server notices na stderr?
Message-ID: <20040213104234.GB1058@bobek.pm.i.cz>

Zdravim,
nevim jestli jsem neschopny hledac, ale ani v manove strance DBI ci
DBD::Pg jsem nezahledl, jak zakazat vypisovani hlasek od serveru
na urovni NOTICE. Take jsem koukal, jestli se to neda nastavit pres
nejaky SET na urovni SQL, ale nic jsem nevidel.

Napr:
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
'enum_pkey' for table 'enum'

Zrejme to vypisuje primo DBD::Pg na STDERR. Hlasky ERROR bych chtel zachovat.
Mam PostgreSQL 7.2.2. DBD::Pg 1.22, DBI je 1.37.
Nevi prosim nekdo?
-- 
Zito

From adelton na informatics.muni.cz  Fri Feb 13 12:45:54 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Fri, 13 Feb 2004 12:45:54 +0100
Subject: PostgreSQL + DBD::Pg - jak zakazat server notices na stderr?
In-Reply-To: <20040213104234.GB1058@bobek.pm.i.cz>
References: <20040213104234.GB1058@bobek.pm.i.cz>
Message-ID: <20040213114554.GG5760@anxur.fi.muni.cz>

On Fri, Feb 13, 2004 at 11:42:34AM +0100, Václav Ovsík wrote:
> nevim jestli jsem neschopny hledac, ale ani v manove strance DBI ci
> DBD::Pg jsem nezahledl, jak zakazat vypisovani hlasek od serveru
> na urovni NOTICE. Take jsem koukal, jestli se to neda nastavit pres
> nejaky SET na urovni SQL, ale nic jsem nevidel.
> 
> Napr:
> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
> 'enum_pkey' for table 'enum'
> 
> Zrejme to vypisuje primo DBD::Pg na STDERR. Hlasky ERROR bych chtel zachovat.
> Mam PostgreSQL 7.2.2. DBD::Pg 1.22, DBI je 1.37.
> Nevi prosim nekdo?

Zupgradujte DBD::Pg na posledni verzi, kdy je mozne notice chytit
(a zahodit :-) pomoci

	$SIG{__WARN__} = sub {};

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From vaclav.ovsik na i.cz  Fri Feb 13 13:20:05 2004
From: vaclav.ovsik na i.cz (=?iso-8859-2?Q?V=E1clav_Ovs=EDk?=)
Date: Fri, 13 Feb 2004 13:20:05 +0100
Subject: PostgreSQL + DBD::Pg - jak zakazat server notices na stderr?
In-Reply-To: <20040213114554.GG5760@anxur.fi.muni.cz>
References: <20040213104234.GB1058@bobek.pm.i.cz> <20040213114554.GG5760@anxur.fi.muni.cz>
Message-ID: <20040213122005.GC1058@bobek.pm.i.cz>

On Fri, Feb 13, 2004 at 12:45:54PM +0100, Honza Pazdziora wrote:
> Zupgradujte DBD::Pg na posledni verzi, kdy je mozne notice chytit
> (a zahodit :-) pomoci
> 
> 	$SIG{__WARN__} = sub {};

Dekuji velmi. To mam docela stesti, ze to nedavno dodelali :-).
Sice jsem puvodne doufal v neco cistsiho, ale jak se zda je tohle zatim
jedina cesta.
-- 
Zito

From Databases na healthe43.com  Sat Feb 14 01:11:08 2004
From: Databases na healthe43.com (Brice Meadows)
Date: Sat, 14 Feb 2004 04:11:08 +0400
Subject: Databases No prior pre scription needed
Message-ID: <ONPBVRZBPMXEQNRHXEQAL@phrames55667.com>

Just like any g e n e r i c pharmaceutical We
Databases,

Just like any generic pharmaceutical, 
our products are less expensive than 
the brand name equivalents.

Generic viagra, at cheap prices.
Most places charge $20, we charge $3. 

Quite a difference, huh? with guarantees to.

Your easy-to-use solution is here: 
http://Databases.sedmeds4.com/gp/default.asp?id=GPH

THX,
Earnest Heath

Databases below is for u if u dislike e-commerce
http://Databases.phrames55667.com/off.html 

From zangukftnyt na freed14.com  Sat Feb 14 12:22:32 2004
From: zangukftnyt na freed14.com (Tisha Pack)
Date: Sat, 14 Feb 2004 12:22:32 +0100
Subject: Take 5O% off Gen|eric Via-gra 0nline tod-ay
Message-ID: <FSQGBZAZOUCCJXDVAMWVGDA@freed14.com>

calico
$2.50 per d0se f0r G|eneric V-i-a-g-r-a. Limited Time Free D-o-c-t-o-r 
fahrenheit
LOW-COST V-i- na -g-r-a
c
Now you can get generic V-i- na -g-r-a for as low as $2.50 per dose,
with a FR|EE physician's consultation and discrete shipment to the
privacy of your home or office.
p
Costs over 60% less than Brand Name
FR|EE Doctor Consultation
FR|EE Shipp|ing
Private delivery to your home
100% M|oney Back G|uarantee
s
FUL|L RE|FUND IF NOT DELIGHTED!
o
Please Visit The Site Below For More Information
http://www.trustrnktrng.com/xm/

t
cry consider irreducible debt hockey glycerin waybill embank font backhand coconut eventide albania partook dolan defiant joy auditory celestial bourgeoisie enquire atomic gorse khrushchev asteria taos  

From mzmxcbhxjjx na chainre.com  Sun Feb 15 15:05:11 2004
From: mzmxcbhxjjx na chainre.com (Nelson Schulz)
Date: Sun, 15 Feb 2004 15:05:11 +0100
Subject: $2.50 per d0se f0r Gener|ic V*i*a*g*r*a. Limited Time F.r.e.e Doctor 
Message-ID: <NPUAGYFOPQAVDPLQCVRKPN@chainre.com>

taunt
60% 0ff G eneric V*i*a*g*r*a, a l-i-m-i-t-e-d time only
crumb
LOW-COST V-i- na -g-r-a
b
Now you can get generic V-i- na -g-r-a for as low as $2.50 per dose,
with a FR|EE physician's consultation and discrete shipment to the
privacy of your home or office.
i
Costs over 60% less than Brand Name
FR|EE Doctor Consultation
FR|EE Shipp|ing
Private delivery to your home
100% M|oney Back G|uarantee
b
FUL|L RE|FUND IF NOT DELIGHTED!
m
Please Visit The Site Below For More Information
http://www.chainre.com/xm/

f
recusant dee cry you'll epithelial mineral tech cursor adriatic ogden cleric  

From armandinaz7 na cisp.com  Mon Feb 16 06:13:20 2004
From: armandinaz7 na cisp.com (armandinaz7 na cisp.com)
Date: Mon, 16 Feb 2004 00:13:20 -0500
Subject: Hi you...
Message-ID: <200402160513.i1G5DKi30838@ipswjr0100atl2.usa.prod.interland.net>

Below is the result of your feedback form.  It was submitted by
armandinaz7 na cisp.com (armandinaz7 na cisp.com) on Monday, February 16, 2004 at 00:13:20
---------------------------------------------------------------------------

g6eghl5: 

Get brand name prescriptions delivered over night to your doorstep. No doctor visits, no prior prescriptions. Our Rx store is 100% descreet. Order medications today and get them tomorrow.

<a href="http://www.budgetmdsource.com/?rid=1019">Click here or below for more info!</a>

...or if your browser is not working correctly copy and paste this URL below:

http://www.budgetmdsource.com/?rid=1019

Thank you. You won't be disappointed.







































qabe1yrzo5qucfa

---------------------------------------------------------------------------


From balas_balasubr na aol.com  Wed Feb 18 05:17:52 2004
From: balas_balasubr na aol.com (bailey balakris)
Date: Wed, 18 Feb 2004 05:17:52 +0100
Subject: Friendly invitation
Message-ID: <200402180417.i1I4HqL12058@paris81.amenworld.com>

Below is the result of your feedback form.  It was submitted by
bailey balakris (balas_balasubr na aol.com) on Wednesday, February 18, 2004 at 05:17:52
---------------------------------------------------------------------------

wslrurSHSX32651: Everyone gets a chance to win huge at the Grand Phoenician.
Just Enter the casino, and receive $250.00 dollars to win the jackpot
Please copy and paste this link into your Web-Browser
http://www.casinos-money.com/_dd15f4abc3faff8f3c43ac8a3f66f869/
If you do not copy and paste that exact link into your Web-Browser you will 
not receive your exclusive access pass.
Do you want the big one to really get away?
package linkage leakage packaged packager packagers leakages.
packages linkages 
packaging packagings lookahead Kankakee balkan jackanapes Spokane balkanize. balkanized balkanizing balkans Packard.bahram

---------------------------------------------------------------------------


From Ales.Zika na pel.br.ds.mfcr.cz  Wed Feb 18 07:45:59 2004
From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=)
Date: Wed, 18 Feb 2004 07:45:59 +0100
Subject: Ceske razeni v PgSQL
Message-ID: <A458B72B045BD811959B0002A562DC41A493@fupelnt2.pel.br.ds.mfcr.cz>


> jenomze k tomu musite mit roota nebo postgres. Mam 
> nainstalovanou 7.5, 
> takze netusim jestli nasledujici dotaz zafunguje na 7.3. U mne lze 
> 
> intra=# SELECT name, setting from pg_settings where name like 'lc%';
>     name     |   setting
> -------------+--------------
>  lc_collate  | cs_CZ.latin2
>  lc_ctype    | cs_CZ.latin2
>  lc_messages | cs_CZ.latin2
>  lc_monetary | cs_CZ.latin2
>  lc_numeric  | cs_CZ.latin2
>  lc_time     | cs_CZ.latin2
> (6 řádek)
> 
> 

	Taxem to zkusil a vybehlo mi :

    name     | setting 
-------------+---------
 lc_messages | cs_CZ
 lc_monetary | cs_CZ
 lc_numeric  | cs_CZ
 lc_time     | cs_CZ
(4 rows)
 
Parametry lc_collate a lc_ctype tam vubec nejsou, je to ten problem?

	A jeste doplnujici dotaz, kodovani databaze mame UNICODE, bude to
spravne radit, kdyby bylo nastavene lc_collate=cs_CZ? Nebo to musi presne
odpovidat a kdyz mam DB v LATIN2, tak musi byt lc-collate=cs_CZ.latin2,
kdbych ji mel ve WIN1250 :-O, tak musi byt lc_collate=windows1250 a jinak to
nepujde? A UNICODE ma proste smulu?
	V locales se moc nevyznam a nevim, co mam vlastně po providerovi
presne chtit, aby to cestinu radilo spravne.


	Diky,

			Ales Zika
			CSE Spoje Pelhrimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz 

From koala na vju.cz  Thu Feb 19 13:09:32 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Thu, 19 Feb 2004 13:09:32 +0100 (CET)
Subject: insert delayed v mysql
Message-ID: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>


Dobre poledne,

v souvislosti s jednim problem si ctu popis INSERT DELAYED pro myisam
tabulky mysql. Hned v prvnim odstavci se pravi, ze tento prikaz muze byt
uzitecny, pokud se dela insert a zaroven se casto pousti SELECT a UPDATE. Proc
ceka INSERT na UPDATE je jasne, ale proc by mel cekat na SELECT?
Uvazuji (stejne jako v mem problemu) se se nedela lock tables.


Pro jistotu jsem na velke tabulce dal casove dlouhy select a nez se data
vratila, mohl jsem davat kolik insertu jsem chtel. Takze zda se, ze neni
ani teoreticky, ani prakticky duvod zminovat SELECT.


citace:
---------------------------------------------------------------------
INSERT DELAYED .


The DELAYED option for the INSERT statement is a MySQL-specific option
that is very useful if you have clients that can't wait for the INSERT to
complete. This is a common problem when you use MySQL for logging and you
also periodically run SELECT and UPDATE statements that take a long time
to complete.



s diky
--
Ondrej Koala Vacha

From zakkr na zf.jcu.cz  Thu Feb 19 13:14:58 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 19 Feb 2004 13:14:58 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
Message-ID: <20040219121457.GG27927@zf.jcu.cz>

On Thu, Feb 19, 2004 at 01:09:32PM +0100, Ondrej Koala Vacha wrote:
> 
> Dobre poledne,
> 
> v souvislosti s jednim problem si ctu popis INSERT DELAYED pro myisam
> tabulky mysql. Hned v prvnim odstavci se pravi, ze tento prikaz muze byt
> uzitecny, pokud se dela insert a zaroven se casto pousti SELECT a UPDATE. Proc
> ceka INSERT na UPDATE je jasne, ale proc by mel cekat na SELECT?
> Uvazuji (stejne jako v mem problemu) se se nedela lock tables.

 Jsou tydle tabulky transakcni? Asi ne.

> Pro jistotu jsem na velke tabulce dal casove dlouhy select a nez se data
> vratila, mohl jsem davat kolik insertu jsem chtel. Takze zda se, ze neni
> ani teoreticky, ani prakticky duvod zminovat SELECT.

 A co treba index a jeho soucasne pouzivani jak selectem tak tema co
 ho modifikuji?

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From koala na vju.cz  Thu Feb 19 17:04:08 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Thu, 19 Feb 2004 17:04:08 +0100 (CET)
Subject: insert delayed v mysql
In-Reply-To: <20040219121457.GG27927@zf.jcu.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
 <20040219121457.GG27927@zf.jcu.cz>
Message-ID: <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>

On Thu, 19 Feb 2004, Karel Zak wrote:

>  Jsou tydle tabulky transakcni? Asi ne.

Ne nejsou, nekolikrat jsem to u dotycneho overoval. Netransakcni, ani
nepouziva lock tables.

>
> > Pro jistotu jsem na velke tabulce dal casove dlouhy select a nez se data
> > vratila, mohl jsem davat kolik insertu jsem chtel. Takze zda se, ze neni
> > ani teoreticky, ani prakticky duvod zminovat SELECT.
>
>  A co treba index a jeho soucasne pouzivani jak selectem tak tema co
>  ho modifikuji?
>

Mhm, to neni spatny napad, ale i v mem zkusebnim pripadu se v tom dlouhem
selectu pouzival tentyz klic (id vety) ktery se insertem menil, tedy se
pridavalo. Ale overim. -- Zminovany problem je takovy, ze 0-30 lidi neco
posila
pres www rozhrani databaze - insert/update/delete a DB samotna dela nejake
selecty. A obcas se stane, ze jeden z klientu na minuty(!) vytuhne. Siti
by to byt nemelo, je to z mistnosti do mistnosti, a deadlock jaksi nema
kde nastat.


s pozdravem
--
Ondrej Koala Vacha

From zakkr na zf.jcu.cz  Thu Feb 19 19:23:20 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 19 Feb 2004 19:23:20 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz> <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
Message-ID: <20040219182320.GI27927@zf.jcu.cz>

On Thu, Feb 19, 2004 at 05:04:08PM +0100, Ondrej Koala Vacha wrote:
> >  A co treba index a jeho soucasne pouzivani jak selectem tak tema co
> >  ho modifikuji?
> >
> 
> Mhm, to neni spatny napad, ale i v mem zkusebnim pripadu se v tom dlouhem
> selectu pouzival tentyz klic (id vety) ktery se insertem menil, tedy se

 Nechci sirit bludy, ale mam pocit,  ze mozna zrovna tyto nebo nektere z
 klasickych typu  MySQL tabulek maji  podil na tom, ze  vsemi obdivovana
 vykonost (merena casto jednim samostatnym  selectem...:-) jde do pryc v
 pripade  konkurencnich pristupu  k  tabulkam. Narozdil  od Oracle  nebo
 PostgreSQL (apod.) kde vykon neni timto zase tak ovlivnen.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From nigho101 na netscape.net  Thu Feb 19 19:42:40 2004
From: nigho101 na netscape.net (Dr Omonigho Omo)
Date: Thu, 19 Feb 2004 19:42:40 +0100
Subject: please read your assistance required
Message-ID: <200402191842.i1JIgVRf031874@anor.ics.muni.cz>

STRICTLY CONFIDENTIAL

I am Dr O.Omonigho, We need your help to recieve the sum of Sixteen million Two hundred and Fifty thousand Dollars (US$16.25M) which represent an over invoiced contract that is floating in our system, Department of Minerals & Energy, South Africa. Please contact me For more information on this email, the deal is 100% hitch free.

I can only transfer the money with the help of a foreign partner hence I contact you, I look forward to be hearing from you via email (nigho na myway.com)

Regards,

Dr.Omonigho Omo.
 
 
  

From adelton na informatics.muni.cz  Fri Feb 20 09:37:56 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Fri, 20 Feb 2004 09:37:56 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz> <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
Message-ID: <20040220083756.GA16242@anxur.fi.muni.cz>

On Thu, Feb 19, 2004 at 05:04:08PM +0100, Ondrej Koala Vacha wrote:
> 
> Ne nejsou, nekolikrat jsem to u dotycneho overoval. Netransakcni, ani
> nepouziva lock tables.

Pak ale server musi tu tabulku interne zamknout. Protoze jinak by
nebyl schopen zajistit, ze dostanete konzistentni vysledek. Mohlo by
se Vam v takovem pripade stat, ze pulku vysledku (toho selectu)
dostanete z doby jeste pred probehnutim insertu a druhou pulku po
dobehnuti insertu.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From koala na vju.cz  Fri Feb 20 09:52:21 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Fri, 20 Feb 2004 09:52:21 +0100 (CET)
Subject: insert delayed v mysql
In-Reply-To: <20040220083756.GA16242@anxur.fi.muni.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
 <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
 <20040220083756.GA16242@anxur.fi.muni.cz>
Message-ID: <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz>

On Fri, 20 Feb 2004, Honza Pazdziora wrote:

> On Thu, Feb 19, 2004 at 05:04:08PM +0100, Ondrej Koala Vacha wrote:
> >
> > Ne nejsou, nekolikrat jsem to u dotycneho overoval. Netransakcni, ani
> > nepouziva lock tables.
>
> Pak ale server musi tu tabulku interne zamknout. Protoze jinak by
> nebyl schopen zajistit, ze dostanete konzistentni vysledek. Mohlo by
> se Vam v takovem pripade stat, ze pulku vysledku (toho selectu)
> dostanete z doby jeste pred probehnutim insertu a druhou pulku po
> dobehnuti insertu.
>

A dela to? Tedy jestli se snazi zajist alespon jakysi konzistentni
vysledek nazvdory tomu, ze aplikace si o nekonzistentnost sam rika tim, ze
nezamyka.


--
Ondrej Koala Vacha

From zakkr na zf.jcu.cz  Fri Feb 20 10:06:09 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Fri, 20 Feb 2004 10:06:09 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz> <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz> <20040220083756.GA16242@anxur.fi.muni.cz> <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz>
Message-ID: <20040220090609.GC3644@zf.jcu.cz>

On Fri, Feb 20, 2004 at 09:52:21AM +0100, Ondrej Koala Vacha wrote:
> On Fri, 20 Feb 2004, Honza Pazdziora wrote:
> 
> > On Thu, Feb 19, 2004 at 05:04:08PM +0100, Ondrej Koala Vacha wrote:
> > >
> > > Ne nejsou, nekolikrat jsem to u dotycneho overoval. Netransakcni, ani
> > > nepouziva lock tables.
> >
> > Pak ale server musi tu tabulku interne zamknout. Protoze jinak by
> > nebyl schopen zajistit, ze dostanete konzistentni vysledek. Mohlo by
> > se Vam v takovem pripade stat, ze pulku vysledku (toho selectu)
> > dostanete z doby jeste pred probehnutim insertu a druhou pulku po
> > dobehnuti insertu.
> >
> 
> A dela to? Tedy jestli se snazi zajist alespon jakysi konzistentni
> vysledek nazvdory tomu, ze aplikace si o nekonzistentnost sam rika tim, ze
> nezamyka.

 Pokud  myslite,  ze by  to  mela  resit  aplikace  a zajistit  si  sama
 konzistenci  dat, aby  nedochazelo  k vzajemnemu  chodu INSERT(apod)  a
 SELECTu tak to se dostavate nekam do "databazoveho" praveku. IMHO prave
 pro zajisteni kozistence dat se DB pouzivaji.

 Neco jako LOCK TABLE je prikaz, ktery  by nemel byt ani v manualu a mel
 se predavat z  generace na generaci databazovych  specialistu jako neco
 tajemneho  a  "co  snad  nekde  pry existuje..."  :-)  (plati  to  i  o
 vyvojarich DB serveru).

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From koala na vju.cz  Fri Feb 20 10:15:11 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Fri, 20 Feb 2004 10:15:11 +0100 (CET)
Subject: insert delayed v mysql
In-Reply-To: <20040220090609.GC3644@zf.jcu.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
 <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
 <20040220083756.GA16242@anxur.fi.muni.cz> <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz>
 <20040220090609.GC3644@zf.jcu.cz>
Message-ID: <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>

On Fri, 20 Feb 2004, Karel Zak wrote:

> > A dela to? Tedy jestli se snazi zajist alespon jakysi konzistentni
> > vysledek nazvdory tomu, ze aplikace si o nekonzistentnost sam rika tim, ze
> > nezamyka.
>
>  Pokud  myslite,  ze by  to  mela  resit  aplikace  a zajistit  si  sama
>  konzistenci  dat, aby  nedochazelo  k vzajemnemu  chodu INSERT(apod)  a
>  SELECTu tak to se dostavate nekam do "databazoveho" praveku. IMHO prave
>  pro zajisteni kozistence dat se DB pouzivaji.


Asi si nerozumime. Ano, Adelton psal o tom, ze pulka insertu projde a
pulka ne. Jasne, tady uznavam, ze jsem to spatne napsal - zde opravdu
vsichni cekame, ze bud precte insert cely nebo neprecte vubec.

Ale neni problem pri zpracovavani jednoho selectu davat inserty, z nichz
nektere select precte a jine nikoli. Tim se sice dostane konzistentni stav
v ramci 1 insertu, ale nikoli v ramci toho selectu a uzivatel si za to
muze sam.

>
>  Neco jako LOCK TABLE je prikaz, ktery  by nemel byt ani v manualu a mel

;)

--
Ondrej Koala Vacha

From Janousek na FoNet.Cz  Fri Feb 20 10:19:31 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Fri, 20 Feb 2004 10:19:31 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A3C@percival.fonet.cz>

> -----Original Message-----
> From: Ondrej Koala Vacha [mailto:koala na vju.cz] 
> nektere select precte a jine nikoli. Tim se sice dostane 
> konzistentni stav
> v ramci 1 insertu, ale nikoli v ramci toho selectu a uzivatel si za to
> muze sam.

	Mozna Vam ted nerozumim, ale problem neni v uzivateli, ale
tvurci systemu => jakykoli konkurentni system bude mit mozny problem - v
pripade GUI via WWW vzdy...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From zakkr na zf.jcu.cz  Fri Feb 20 10:47:59 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Fri, 20 Feb 2004 10:47:59 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz> <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz> <20040220083756.GA16242@anxur.fi.muni.cz> <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz> <20040220090609.GC3644@zf.jcu.cz> <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
Message-ID: <20040220094759.GD3644@zf.jcu.cz>

On Fri, Feb 20, 2004 at 10:15:11AM +0100, Ondrej Koala Vacha wrote:
> Asi si nerozumime. Ano, Adelton psal o tom, ze pulka insertu projde a
> pulka ne. Jasne, tady uznavam, ze jsem to spatne napsal - zde opravdu
> vsichni cekame, ze bud precte insert cely nebo neprecte vubec.

 Uz si rozumime :-)

> Ale neni problem pri zpracovavani jednoho selectu davat inserty, z nichz
> nektere select precte a jine nikoli. Tim se sice dostane konzistentni stav
> v ramci 1 insertu, ale nikoli v ramci toho selectu a uzivatel si za to
> muze sam.

 Pak tedy spojit ty inserty do jedne transakce. Ostatne i ta MySQL by
 uz mela umet v tomdle pomoct.


-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From koala na vju.cz  Fri Feb 20 10:48:15 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Fri, 20 Feb 2004 10:48:15 +0100 (CET)
Subject: insert delayed v mysql
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF4430178A3C@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A3C@percival.fonet.cz>
Message-ID: <Pine.LNX.4.58.0402201045230.19644@darkstar.vju.cz>

On Fri, 20 Feb 2004, Ing. Pavel Janousek wrote:

> > -----Original Message-----
> > From: Ondrej Koala Vacha [mailto:koala na vju.cz]
> > nektere select precte a jine nikoli. Tim se sice dostane
> > konzistentni stav
> > v ramci 1 insertu, ale nikoli v ramci toho selectu a uzivatel si za to
> > muze sam.
>
> 	Mozna Vam ted nerozumim, ale problem neni v uzivateli, ale
> tvurci systemu => jakykoli konkurentni system bude mit mozny problem - v
> pripade GUI via WWW vzdy...

Opet moje nepresne vyjadreni :( - ne samozrejme uzivatel zadavajici data
pres www, ale tvurce toho systemu, co tato data posila do DB. Myslel jsem
to obecne - pokud nekdo posila data do DB a zaroven dela selecty, pak muze
cekat potize.


--
Ondrej Koala Vacha

From Janousek na FoNet.Cz  Fri Feb 20 10:52:49 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Fri, 20 Feb 2004 10:52:49 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402201045230.19644@darkstar.vju.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A3F@percival.fonet.cz>

> -----Original Message-----
> From: Ondrej Koala Vacha [mailto:koala na vju.cz] 
> pres www, ale tvurce toho systemu, co tato data posila do DB. 
> Myslel jsem
> to obecne - pokud nekdo posila data do DB a zaroven dela 
> selecty, pak muze
> cekat potize.

	No může a nemusí - stačí, aby DB operace byla sólo vrstva a
třeba pomocí vhodné serializace nemusí mít problém - třeba mu stačí
"implementace" artefaktů z jazyka SQL a efektivní ukládání +
optimalizované vyhledávání bez nutnosti vlastní implementace. Věřím, že
i tento případ může reálně nastat - ostatně třeba celé libdbX (*) je
přece o tomto - efektivní uložení a výběr, bez dalších features.

(*) X je dneska už 1 až 4 (5 - ?)

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From adelton na informatics.muni.cz  Fri Feb 20 11:04:11 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Fri, 20 Feb 2004 11:04:11 +0100
Subject: insert delayed v mysql
In-Reply-To: <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz> <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz> <20040220083756.GA16242@anxur.fi.muni.cz> <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz> <20040220090609.GC3644@zf.jcu.cz> <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
Message-ID: <20040220100411.GE16242@anxur.fi.muni.cz>

On Fri, Feb 20, 2004 at 10:15:11AM +0100, Ondrej Koala Vacha wrote:
> >
> >  Pokud  myslite,  ze by  to  mela  resit  aplikace  a zajistit  si  sama
> >  konzistenci  dat, aby  nedochazelo  k vzajemnemu  chodu INSERT(apod)  a
> >  SELECTu tak to se dostavate nekam do "databazoveho" praveku. IMHO prave
> >  pro zajisteni kozistence dat se DB pouzivaji.
> 
> Asi si nerozumime. Ano, Adelton psal o tom, ze pulka insertu projde a
> pulka ne. Jasne, tady uznavam, ze jsem to spatne napsal - zde opravdu

Ne, ja jsem psal, ze v prubehu zpracovavani insertu muze probihat
select. Je nepripustne, abyste v tom selectu videl prvni pulku ve
stavu pred provedenim insertu a druhou ve stavu po provedeni insertu.
Da se to resit dvema zpusoby: pomoci multiversion control, tedy
transakce -- v jednu chvili je uchovavano vice verzi tech samych zaznamu
a kazda session muze videt neco jineho, v MySQL tabulky InnoDB a
BerkeleyDB, nebo pomoci zamku.

> Ale neni problem pri zpracovavani jednoho selectu davat inserty, z nichz
> nektere select precte a jine nikoli. Tim se sice dostane konzistentni stav

Ruzne inserty samozrejme ano. Ale ne pulku insertu (insert select muze
insertovat vice nez jeden zaznam).

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From koala na vju.cz  Fri Feb 20 12:20:41 2004
From: koala na vju.cz (Ondrej Koala Vacha)
Date: Fri, 20 Feb 2004 12:20:41 +0100 (CET)
Subject: insert delayed v mysql
In-Reply-To: <20040220094759.GD3644@zf.jcu.cz>
References: <Pine.LNX.4.58.0402191302530.18762@darkstar.vju.cz>
 <20040219121457.GG27927@zf.jcu.cz> <Pine.LNX.4.58.0402191656370.2100@darkstar.vju.cz>
 <20040220083756.GA16242@anxur.fi.muni.cz> <Pine.LNX.4.58.0402200949290.31174@darkstar.vju.cz>
 <20040220090609.GC3644@zf.jcu.cz> <Pine.LNX.4.58.0402201010300.22198@darkstar.vju.cz>
 <20040220094759.GD3644@zf.jcu.cz>
Message-ID: <Pine.LNX.4.58.0402201218400.16545@darkstar.vju.cz>

On Fri, 20 Feb 2004, Karel Zak wrote:

>
>  Pak tedy spojit ty inserty do jedne transakce. Ostatne i ta MySQL by
>  uz mela umet v tomdle pomoct.
>


Prechod na innodb jsem take poradil, ale spis by me zajimala pricina tech
zdrzeni - bez ohledu na to, ze z pohledu konzistence dotazu je to
nestastne napsane.

--
Ondrej Koala Vacha

From webmaster na tony.cz  Fri Feb 20 14:21:24 2004
From: webmaster na tony.cz (Michal Samek)
Date: 20 Feb 2004 14:21:24 +0100
Subject: Jak na browse velke tabulky v sql ?
Message-ID: <1077283283.1360.79.camel@localhost.localdomain>

Dobry den,
omlouvam se, jestli se to tu uz nejak resilo... Podotykam, jsem byvaly
vyvojar pro xbase, sql dneska celkem bezne pouzivam, ale tomuhle proste
porad nerozumim. Pripada mi, ze je sql na neco ok a na neco uz moc ne...

Chtel bych prepsat nejakou aplikaci z doby dosu a xbase systemu. Vsichni
tvrdi, ze dnes je xbase v podstate mrtve a vyhody sql prevazuji atd. Jak
se ale resi browsing velkych tabulek? Mam treba nejaky katalog o 150000
zaznamech a chci si v nem listovat, s moznosti prepnout setrideni z
nekolika moznych a s inkrementalnim vyhledavanim. V clipperu je to
jednoduche, program v podstate "chodi" po tabulce na nejakem indexu a
muze inkrementalne seekovat. Navic to cele automaticky reaguje na zmeny
tech prohlizenych dat (jakmile vypadnou z bufferu nebo kdyz si to
vyzadam) Ale v sql ve spojeni s nejakym beznym gui? Vsechno, co mne
napada, je tak pomale nebo pametove narocne, ze je to v praxi
nepouzitelne, z pohledu uzivatele te stare xbase aplikace kazdopadne.
Nacist celou tabulku do gui objektu je pomale a zabere moc mista. Navic
bych pak nevidel zmeny. Nacitat pomoci offsetu je asi jedine reseni, to
ale budu bombardovat server neustalymi queries? Kazda se musi
preparsovat, zoptimalizovat a provest a navic si nejsem jisty, zda si
server vlastne pokazde nevytvori nejakou pracovni kopii celeho vysledku,
ze ktere mi pak vraci jenom cast (to by bylo brutalne neefektivni). A
zminene inkrementalni hledani? To uz vubec nevim. Taky potrebuju
prubezne vedet, kolik tech polozek v danem okamziku vidim, to znamena
porad se ptat select count... Nebo treba prepnuti setrideni, ale tak,
abych zustal porad na aktualnim zaznamu? Jak na tohle jit jednoduse,
netusim. Musel bych v danem setrideni zjistit pozici aktualniho zaznamu,
treba select vsechno a v tom to pak dohledat? Hruza. Resit to vsechno v
sql je oproti te "stare a nevykonne" xbase strasne pracne. Nebo existuji
nejake gui objekty, ktere umoznuji inteligentni napojeni na sql? Co na
to cele rikate? Unika mi neco? Diky za kazdy komentar...

-- 
Michal Samek <webmaster na tony.cz>


From sherry na pikebo.cz  Fri Feb 20 14:02:34 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Fri, 20 Feb 2004 14:02:34 +0100
Subject: Jak na browse velke tabulky v sql ?
References: <1077283283.1360.79.camel@localhost.localdomain>
Message-ID: <4036056A.8000504@pikebo.cz>

Michal Samek wrote:
> Chtel bych prepsat nejakou aplikaci z doby dosu a xbase systemu. Vsichni
> tvrdi, ze dnes je xbase v podstate mrtve a vyhody sql prevazuji atd. Jak
> se ale resi browsing velkych tabulek? Mam treba nejaky katalog o 150000
> zaznamech a chci si v nem listovat, s moznosti prepnout setrideni z
> nekolika moznych a s inkrementalnim vyhledavanim. 

Predne: kdyz ma tabulka 150000 zaznamu (trosku maly pocet na velkou 
tabulku, kterou uvadite v subjectu, nechybi tam 3 nuly? ;-)
a chcete prohlizet jeji obsah, tak je asi blbost poslat na server dotaz 
SELECT * FROM tabulka (i kdyz i to si lze predstavit napr. na urovni 
Oracle Call Interface).

Pri psani prohlizece je hlavni vzit rozum do hrsti a uvazovat, kdy je 
nutne zeptat se na data a kdy ne, zda uzivatel preferuje konzistentni 
pohled na data v prubehu prohlizeni (chce mit jistotu, ze i po pulhodine 
klikani vidi data stejne stara jako ta, ktera videl na prvni zobrazene 
obrazovce pred pul hodinou) nebo maximalni aktualnost zobrazenych dat.

Pokud hledate inspiraci, tak na http://www.globecom.se/tora sedi projekt
TOra, ktery je a) dostupny se zdroji a b) jeden z jeho modulu je prave 
prohlizec tabulky.

Jan Serak



From spec_list na tony.cz  Fri Feb 20 15:09:46 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 15:09:46 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4036056A.8000504@pikebo.cz>
References: <1077283283.1360.79.camel@localhost.localdomain>
	 <4036056A.8000504@pikebo.cz>
Message-ID: <1077286185.2638.99.camel@localhost.localdomain>

V Pá, 20. 02. 2004 v 14.02, Jan Serak napsal:
> Michal Samek wrote:
> > Chtel bych prepsat nejakou aplikaci z doby dosu a xbase systemu. Vsichni
> > tvrdi, ze dnes je xbase v podstate mrtve a vyhody sql prevazuji atd. Jak
> > se ale resi browsing velkych tabulek? Mam treba nejaky katalog o 150000
> > zaznamech a chci si v nem listovat, s moznosti prepnout setrideni z
> > nekolika moznych a s inkrementalnim vyhledavanim. 
> 
> Predne: kdyz ma tabulka 150000 zaznamu (trosku maly pocet na velkou 
> tabulku, kterou uvadite v subjectu, nechybi tam 3 nuly? ;-)
> a chcete prohlizet jeji obsah, tak je asi blbost poslat na server dotaz 
> SELECT * FROM tabulka (i kdyz i to si lze predstavit napr. na urovni 
> Oracle Call Interface).

:) Ne ja nechci brat rozum do zadne hrsti, chci pouze dosahnout stejne
fukncnosti, na jakou jsou uzivatele zvykli. Proste to tak je. A 150000
zaznamu mi pripada jako dost na to, abych je nedrzel v pameti gui
objektu. Klidne jich muze byt vice, jde mi o princip. A take pozadavek
na jejich prubeznou aktualizaci je proste fakt, toto je zrovna misto,
kde chci videt ziva data (drobne zpozdeni nevadi). Ze je blbost to
natahovat cele najednou tvrdite vzapeti i vy. Jde mi opravdu o to, jak
se v sql dosahne pozadovane funkcnosti, ovsem opravdu se vsim - zmena
setrideni bez ztraty pozice, inkr. vyhledavani atd. Moc nerozumim, co
jste se mi snazil sdelit...


-- 
Michal Samek <spec_list na tony.cz>


From janousek na fonet.cz  Fri Feb 20 14:26:14 2004
From: janousek na fonet.cz (=?iso-8859-2?Q?Pavel_Janou=B9ek?=)
Date: Fri, 20 Feb 2004 14:26:14 +0100
Subject: Jak na browse velke tabulky v sql ?
Message-ID: <4F23E9745D562F4D90373B9C5CEF44302302E5@percival.fonet.cz>

> -----Original Message-----
> From: Michal Samek [mailto:spec_list na tony.cz] 
> kde chci videt ziva data (drobne zpozdeni nevadi). Ze je blbost to
> natahovat cele najednou tvrdite vzapeti i vy. Jde mi opravdu o to, jak
> se v sql dosahne pozadovane funkcnosti, ovsem opravdu se vsim - zmena
> setrideni bez ztraty pozice, inkr. vyhledavani atd. Moc nerozumim, co
> jste se mi snazil sdelit...

	Kurzory, a doporucuji Vasi pozornosti limity a offsety v SELECT.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------

From kluvanek na tesnet.cz  Fri Feb 20 14:26:08 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 14:26:08 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077283283.1360.79.camel@localhost.localdomain>
References: <1077283283.1360.79.camel@localhost.localdomain>
Message-ID: <40360AF0.2040204@trb.tesnet.cz>

Michal Samek napsal(a):
Podla mna je to ale skorej logicky problem.
Ked si predstavim DB v ktorej by mal napriklad kazdy obyvatel sveta jeden 
zaznam, ma vyznam browsovat globalne celou tabulkou a nieco si tam BROWSOVANIM 
zistovat?
Asi nie, ked si uvedomim, ze pravdepodonne za sekundu sa zmeni viac zaznamov, 
ako stihnem precitat.
Cize podla mna va vyznam robit bud nejake statisticke alebo ine matematicke 
operacie nad datami, alebo si vybrat nejaku OBMEDZENU mnozinu zaznamov (nejakym 
filtrom, vyberovymi podmienkami) ktore som schopny obsiahnut.

Naco mi je moznost linearne listovat milionmi alebo miliardami zaznamov?

A tato otazka, pripadne s nou spojene problemy nemaju podla mna az tak moc 
spolocne s tym, ci je to clipper alebo SQL.
Bud to musim cele uzamknut pre vyhradny pristup,
alebo sa tym neda listovat tak, aby sa nestalo, ze niekto zmeni to, co som uz 
precital.
Samotne listovanie/ bufferovanie predsa nieje problem ani v SQL, len je mi to 
stejne podivne, ako keby chcel niekto v Autocade programovat devicedriver.


> Dobry den,
> omlouvam se, jestli se to tu uz nejak resilo... Podotykam, jsem byvaly
> vyvojar pro xbase, sql dneska celkem bezne pouzivam, ale tomuhle proste
> porad nerozumim. Pripada mi, ze je sql na neco ok a na neco uz moc ne...
> 
> Chtel bych prepsat nejakou aplikaci z doby dosu a xbase systemu. Vsichni
> tvrdi, ze dnes je xbase v podstate mrtve a vyhody sql prevazuji atd. Jak
> se ale resi browsing velkych tabulek? Mam treba nejaky katalog o 150000
> zaznamech a chci si v nem listovat, s moznosti prepnout setrideni z
> nekolika moznych a s inkrementalnim vyhledavanim. V clipperu je to
> jednoduche, program v podstate "chodi" po tabulce na nejakem indexu a
> muze inkrementalne seekovat. Navic to cele automaticky reaguje na zmeny
> tech prohlizenych dat (jakmile vypadnou z bufferu nebo kdyz si to
> vyzadam) Ale v sql ve spojeni s nejakym beznym gui? Vsechno, co mne
> napada, je tak pomale nebo pametove narocne, ze je to v praxi
> nepouzitelne, z pohledu uzivatele te stare xbase aplikace kazdopadne.
> Nacist celou tabulku do gui objektu je pomale a zabere moc mista. Navic
> bych pak nevidel zmeny. Nacitat pomoci offsetu je asi jedine reseni, to
> ale budu bombardovat server neustalymi queries? Kazda se musi
> preparsovat, zoptimalizovat a provest a navic si nejsem jisty, zda si
> server vlastne pokazde nevytvori nejakou pracovni kopii celeho vysledku,
> ze ktere mi pak vraci jenom cast (to by bylo brutalne neefektivni). A
> zminene inkrementalni hledani? To uz vubec nevim. Taky potrebuju
> prubezne vedet, kolik tech polozek v danem okamziku vidim, to znamena
> porad se ptat select count... Nebo treba prepnuti setrideni, ale tak,
> abych zustal porad na aktualnim zaznamu? Jak na tohle jit jednoduse,
> netusim. Musel bych v danem setrideni zjistit pozici aktualniho zaznamu,
> treba select vsechno a v tom to pak dohledat? Hruza. Resit to vsechno v
> sql je oproti te "stare a nevykonne" xbase strasne pracne. Nebo existuji
> nejake gui objekty, ktere umoznuji inteligentni napojeni na sql? Co na
> to cele rikate? Unika mi neco? Diky za kazdy komentar...
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From kluvanek na tesnet.cz  Fri Feb 20 14:44:56 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 14:44:56 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF44302302E5@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF44302302E5@percival.fonet.cz>
Message-ID: <40360F58.3010701@trb.tesnet.cz>

Pavel Janoušek napsal(a):

>>-----Original Message-----
>>From: Michal Samek [mailto:spec_list na tony.cz] 
>>kde chci videt ziva data (drobne zpozdeni nevadi). Ze je blbost to
>>natahovat cele najednou tvrdite vzapeti i vy. Jde mi opravdu o to, jak
>>se v sql dosahne pozadovane funkcnosti, ovsem opravdu se vsim - zmena
>>setrideni bez ztraty pozice, inkr. vyhledavani atd. Moc nerozumim, co
>>jste se mi snazil sdelit...
> 
> 
> 	Kurzory, a doporucuji Vasi pozornosti limity a offsety v SELECT.
Ano, to som mal na mysli, je to jednoduche, ale neviem, naco je kurzor, ktory ma 
vybranych 100tisice zaznamov a niekto sa v nom chce hrabat a niekto iny medzitym 
data modifikuje....




> 
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From spec_list na tony.cz  Fri Feb 20 15:37:07 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 15:37:07 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF44302302E5@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF44302302E5@percival.fonet.cz>
Message-ID: <1077287826.1357.104.camel@localhost.localdomain>

V Pá, 20. 02. 2004 v 14.26, Pavel Janoušek napsal:
> > -----Original Message-----
> > From: Michal Samek [mailto:spec_list na tony.cz] 
> > kde chci videt ziva data (drobne zpozdeni nevadi). Ze je blbost to
> > natahovat cele najednou tvrdite vzapeti i vy. Jde mi opravdu o to, jak
> > se v sql dosahne pozadovane funkcnosti, ovsem opravdu se vsim - zmena
> > setrideni bez ztraty pozice, inkr. vyhledavani atd. Moc nerozumim, co
> > jste se mi snazil sdelit...
> 
> 	Kurzory, a doporucuji Vasi pozornosti limity a offsety v SELECT.

Ano, ale to jsem prece sam napsal v puvodnim dotazu. Jde mi o to, ze mi
to pripada cele prilis slozite (oproti xbase, kde to je prirozene
elegantne resitelne), tak mne zajima, zda mi neco zasadniho neuniklo :) 
A navic porad nevim, jak mam po zmene setrideni zjistit pozici daneho
zaznamu v jinem orderu, aniz by se z toho stalo totalne pomale monstrum.
Proste zmenim setrideni a v tu chvili nevim, jaky offset pouzit, aby mi
zaznam pod kurzorem (ten graficky, ne db) zustal stejny. 

-- 
Michal Samek <spec_list na tony.cz>


From spec_list na tony.cz  Fri Feb 20 15:45:16 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 15:45:16 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <40360AF0.2040204@trb.tesnet.cz>
References: <1077283283.1360.79.camel@localhost.localdomain>
	 <40360AF0.2040204@trb.tesnet.cz>
Message-ID: <1077288314.1360.113.camel@localhost.localdomain>

Ach jo, proste chci a musim zachovat funkcnost puvodniho systemu, kde
centrem kazdeho modulu je tabulka, ktera se da i filtrovat, ale zaznam
hledame vyberem spravneho setrideni a inkrementalnim hledanim vetsinou
na celem rozsahu dat  - nebo alespon u nekterych operaci. Hledate
nejakou vec v katalogu hud. nosicu - zkousim cislo, nebere, prepnu
setrideni na nazev, zkousim nazev, za chvili jiny, taky nic, prepnu se
na order titul, zkousim to s the, pak bez, neco najdu, je to podobne ale
neni to ono, tak to prepnu treba zpet na cislo a podivam se kolem,
protoze to muze byt hned vedle atd. To byste museli znat ten b****l v
teto branzi. Ten system je opravdu ergonomicky a produktivni, o tom
proste nema smysl diskutovat. Howgh. Diskutujme o implementaci v sql
(konkretne asi postgres) a mozna i o (ne)vhodnosti pouziti sql v tomto
pripade. Vubec mi nevadi, opakuji, vubec, ze se mi pod rukama ty zaznamy
mohou menit. Naopak to chci videt. Tam, kde je to treba, je zaznam
zamcen proti editaci a to staci.


V Pá, 20. 02. 2004 v 14.26, Kluvanek Martin napsal:
> Michal Samek napsal(a):
> Podla mna je to ale skorej logicky problem.
> Ked si predstavim DB v ktorej by mal napriklad kazdy obyvatel sveta jeden 
> zaznam, ma vyznam browsovat globalne celou tabulkou a nieco si tam BROWSOVANIM 
> zistovat?
> Asi nie, ked si uvedomim, ze pravdepodonne za sekundu sa zmeni viac zaznamov, 
> ako stihnem precitat.
> Cize podla mna va vyznam robit bud nejake statisticke alebo ine matematicke 
> operacie nad datami, alebo si vybrat nejaku OBMEDZENU mnozinu zaznamov (nejakym 
> filtrom, vyberovymi podmienkami) ktore som schopny obsiahnut.
> 
> Naco mi je moznost linearne listovat milionmi alebo miliardami zaznamov?
> 
> A tato otazka, pripadne s nou spojene problemy nemaju podla mna az tak moc 
> spolocne s tym, ci je to clipper alebo SQL.
> Bud to musim cele uzamknut pre vyhradny pristup,
> alebo sa tym neda listovat tak, aby sa nestalo, ze niekto zmeni to, co som uz 
> precital.
> Samotne listovanie/ bufferovanie predsa nieje problem ani v SQL, len je mi to 
> stejne podivne, ako keby chcel niekto v Autocade programovat devicedriver.
> 
> 
> > Dobry den,
> > omlouvam se, jestli se to tu uz nejak resilo... Podotykam, jsem byvaly
> > vyvojar pro xbase, sql dneska celkem bezne pouzivam, ale tomuhle proste
> > porad nerozumim. Pripada mi, ze je sql na neco ok a na neco uz moc ne...
> > 
> > Chtel bych prepsat nejakou aplikaci z doby dosu a xbase systemu. Vsichni
> > tvrdi, ze dnes je xbase v podstate mrtve a vyhody sql prevazuji atd. Jak
> > se ale resi browsing velkych tabulek? Mam treba nejaky katalog o 150000
> > zaznamech a chci si v nem listovat, s moznosti prepnout setrideni z
> > nekolika moznych a s inkrementalnim vyhledavanim. V clipperu je to
> > jednoduche, program v podstate "chodi" po tabulce na nejakem indexu a
> > muze inkrementalne seekovat. Navic to cele automaticky reaguje na zmeny
> > tech prohlizenych dat (jakmile vypadnou z bufferu nebo kdyz si to
> > vyzadam) Ale v sql ve spojeni s nejakym beznym gui? Vsechno, co mne
> > napada, je tak pomale nebo pametove narocne, ze je to v praxi
> > nepouzitelne, z pohledu uzivatele te stare xbase aplikace kazdopadne.
> > Nacist celou tabulku do gui objektu je pomale a zabere moc mista. Navic
> > bych pak nevidel zmeny. Nacitat pomoci offsetu je asi jedine reseni, to
> > ale budu bombardovat server neustalymi queries? Kazda se musi
> > preparsovat, zoptimalizovat a provest a navic si nejsem jisty, zda si
> > server vlastne pokazde nevytvori nejakou pracovni kopii celeho vysledku,
> > ze ktere mi pak vraci jenom cast (to by bylo brutalne neefektivni). A
> > zminene inkrementalni hledani? To uz vubec nevim. Taky potrebuju
> > prubezne vedet, kolik tech polozek v danem okamziku vidim, to znamena
> > porad se ptat select count... Nebo treba prepnuti setrideni, ale tak,
> > abych zustal porad na aktualnim zaznamu? Jak na tohle jit jednoduse,
> > netusim. Musel bych v danem setrideni zjistit pozici aktualniho zaznamu,
> > treba select vsechno a v tom to pak dohledat? Hruza. Resit to vsechno v
> > sql je oproti te "stare a nevykonne" xbase strasne pracne. Nebo existuji
> > nejake gui objekty, ktere umoznuji inteligentni napojeni na sql? Co na
> > to cele rikate? Unika mi neco? Diky za kazdy komentar...
> > 
-- 
Michal Samek <spec_list na tony.cz>


From horak na sitmp.cz  Fri Feb 20 14:54:55 2004
From: horak na sitmp.cz (=?iso-8859-2?Q?Hor=E1k_Daniel?=)
Date: Fri, 20 Feb 2004 14:54:55 +0100
Subject: Jak na browse velke tabulky v sql ?
Message-ID: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>

> Ano, ale to jsem prece sam napsal v puvodnim dotazu. Jde mi o 
> to, ze mi
> to pripada cele prilis slozite (oproti xbase, kde to je prirozene
> elegantne resitelne), tak mne zajima, zda mi neco zasadniho 
> neuniklo :) 
> A navic porad nevim, jak mam po zmene setrideni zjistit pozici daneho
> zaznamu v jinem orderu, aniz by se z toho stalo totalne 
> pomale monstrum.
> Proste zmenim setrideni a v tu chvili nevim, jaky offset 
> pouzit, aby mi
> zaznam pod kurzorem (ten graficky, ne db) zustal stejny. 

U zaznamu, ktery je "vybrany" si zapamatujete hodnotu primarniho klice a
podle te se zaznam v "browseru" zase (po setrideni) najde.

Ale docilit shodneho chovani u SQL jakou xBase nejde bez velmi velkeho
usili. Sam jsem vytvarel GUI prvky pro pristup k datum v SQL serverech
do knihovny wxWindows ;-)

Elegance v xbase mozna je, ale jak se zachova pri zmenach provadenych
soucasne nekolika klienty.


			Dan

From janousek na fonet.cz  Fri Feb 20 14:57:07 2004
From: janousek na fonet.cz (=?iso-8859-2?Q?Pavel_Janou=B9ek?=)
Date: Fri, 20 Feb 2004 14:57:07 +0100
Subject: Jak na browse velke tabulky v sql ?
Message-ID: <4F23E9745D562F4D90373B9C5CEF44302302F2@percival.fonet.cz>

> -----Original Message-----
> From: Michal Samek [mailto:spec_list na tony.cz] 
> elegantne resitelne), tak mne zajima, zda mi neco zasadniho 
> neuniklo :) 

	Uniklo - 3 a více-vrstvý model...:-)

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------

From kluvanek na tesnet.cz  Fri Feb 20 15:01:36 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 15:01:36 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077288314.1360.113.camel@localhost.localdomain>
References: <1077283283.1360.79.camel@localhost.localdomain>	 <40360AF0.2040204@trb.tesnet.cz> <1077288314.1360.113.camel@localhost.localdomain>
Message-ID: <40361340.60102@trb.tesnet.cz>

Michal Samek napsal(a):

> Ach jo, proste chci a musim zachovat funkcnost puvodniho systemu, kde
> centrem kazdeho modulu je tabulka, ktera se da i filtrovat, ale zaznam
> hledame vyberem spravneho setrideni a inkrementalnim hledanim vetsinou
> na celem rozsahu dat  - nebo alespon u nekterych operaci. Hledate
> nejakou vec v katalogu hud. nosicu - zkousim cislo, nebere, prepnu
> setrideni na nazev, zkousim nazev, za chvili jiny, taky nic, prepnu se
> na order titul, zkousim to s the, pak bez, neco najdu, je to podobne ale
> neni to ono, tak to prepnu treba zpet na cislo a podivam se kolem,
> protoze to muze byt hned vedle atd. To byste museli znat ten b****l v
> teto branzi. Ten system je opravdu ergonomicky a produktivni, o tom
> proste nema smysl diskutovat. Howgh. Diskutujme o implementaci v sql
> (konkretne asi postgres) a mozna i o (ne)vhodnosti pouziti sql v tomto
> pripade. 

> Vubec mi nevadi, opakuji, vubec, ze se mi pod rukama ty zaznamy
> mohou menit. Naopak to chci videt. Tam, kde je to treba, je zaznam
> zamcen proti editaci a to staci.
Ale co sa ma stat, ked ten zaznam niekto meni/zmenil?
A co ked je zamcen?


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From spec_list na tony.cz  Fri Feb 20 15:55:00 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 15:55:00 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
Message-ID: <1077288899.2638.120.camel@localhost.localdomain>


> 
> U zaznamu, ktery je "vybrany" si zapamatujete hodnotu primarniho klice a
> podle te se zaznam v "browseru" zase (po setrideni) najde.

Jak? Ja potrebuji zacatek (offset) vyjadreny jako cislo, jako pozice. To
je mi jasne, ze muzu zaznam primo vybrat, ale to mi prece nepomuze. Nebo
jsem uplne blby (dneska bych se nedivil). Nebo to myslite tak, ze do
toho gui objektu nacitate vsechny radky a to ja prave nechci, ja chci
selectovat jen kratsi useky podle potreby (zastrankuju --> select treba
50 dalsich zaznamu).

> 
> Ale docilit shodneho chovani u SQL jakou xBase nejde bez velmi velkeho
> usili. Sam jsem vytvarel GUI prvky pro pristup k datum v SQL serverech
> do knihovny wxWindows ;-)

ha, na to se musim podivat. O to mi slo, ze uz nekdo prece tohle musel
nejak resit.

> 
> Elegance v xbase mozna je, ale jak se zachova pri zmenach provadenych
> soucasne nekolika klienty.

No jak, normalne :) Dnes se sice uz zaznamy nezamykaji, mame transakce,
ale fakt je, ze tento klasicky pristup zamykat zaznam nejakou zvlastni
nahodou presne vyhovuje logice prace toho systemu a vubec nijak se tim
necitime omezovani. Nedela nas sice najednou zrovna 1000, ale to je asi
jedno. Stejne nema logiku, aby prijemku plnili soucasne 2 lide...

> 
> 
> 			Dan
-- 
Michal Samek <spec_list na tony.cz>


From kluvanek na tesnet.cz  Fri Feb 20 15:08:59 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 15:08:59 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077288899.2638.120.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain>
Message-ID: <403614FB.2060608@trb.tesnet.cz>

Sorry za O.T. ale niekto tu ma cas pekne popredu...(michal samek)
:-)


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From spec_list na tony.cz  Fri Feb 20 16:00:52 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 16:00:52 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF44302302F2@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF44302302F2@percival.fonet.cz>
Message-ID: <1077289251.1365.126.camel@localhost.localdomain>

> 	Uniklo - 3 a více-vrstvý model...:-)

Tak nevim, je to vtip? Nebo usmev? 

Zacinam se smirovat s tim, ze to, co udelam v xbase na par radku, se moc
dobre a elegantne v sql asi udelat neda (konkretne to, co chci, jinak
spousta veci asi ano). Je to sice bajecne zapouzdrene, ale vykonnejsi to
vubec byt nemusi. A jednodussi na kodovani taky ne. 

-- 
Michal Samek <spec_list na tony.cz>


From Janousek na FoNet.Cz  Fri Feb 20 15:11:00 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Fri, 20 Feb 2004 15:11:00 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077288899.2638.120.camel@localhost.localdomain>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A4C@percival.fonet.cz>

> -----Original Message-----
> From: Michal Samek [mailto:spec_list na tony.cz] 
> jedno. Stejne nema logiku, aby prijemku plnili soucasne 2 lide...

	To ne, ale aby 5 lidi soucasne odepisovalo RUZNE veci ze skladu
a tvorilo dodaky uz ano...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From spec_list na tony.cz  Fri Feb 20 16:03:53 2004
From: spec_list na tony.cz (Michal Samek)
Date: 20 Feb 2004 16:03:53 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <40361340.60102@trb.tesnet.cz>
References: <1077283283.1360.79.camel@localhost.localdomain>
	 <40360AF0.2040204@trb.tesnet.cz>
	 <1077288314.1360.113.camel@localhost.localdomain>
	 <40361340.60102@trb.tesnet.cz>
Message-ID: <1077289432.1365.130.camel@localhost.localdomain>

V Pá, 20. 02. 2004 v 15.01, Kluvanek Martin napsal:
> Michal Samek napsal(a):
> 
> > Ach jo, proste chci a musim zachovat funkcnost puvodniho systemu, kde
> > centrem kazdeho modulu je tabulka, ktera se da i filtrovat, ale zaznam
> > hledame vyberem spravneho setrideni a inkrementalnim hledanim vetsinou
> > na celem rozsahu dat  - nebo alespon u nekterych operaci. Hledate
> > nejakou vec v katalogu hud. nosicu - zkousim cislo, nebere, prepnu
> > setrideni na nazev, zkousim nazev, za chvili jiny, taky nic, prepnu se
> > na order titul, zkousim to s the, pak bez, neco najdu, je to podobne ale
> > neni to ono, tak to prepnu treba zpet na cislo a podivam se kolem,
> > protoze to muze byt hned vedle atd. To byste museli znat ten b****l v
> > teto branzi. Ten system je opravdu ergonomicky a produktivni, o tom
> > proste nema smysl diskutovat. Howgh. Diskutujme o implementaci v sql
> > (konkretne asi postgres) a mozna i o (ne)vhodnosti pouziti sql v tomto
> > pripade. 
> 
> > Vubec mi nevadi, opakuji, vubec, ze se mi pod rukama ty zaznamy
> > mohou menit. Naopak to chci videt. Tam, kde je to treba, je zaznam
> > zamcen proti editaci a to staci.
> Ale co sa ma stat, ked ten zaznam niekto meni/zmenil?

Nic, akorat bych to do nejakeho rozumneho casoveho limitu chtel videt
(treba 10s), pokud se na to zrovna divam.

> A co ked je zamcen?

No tak je zamcen :) ne vazne pokud nekdo edituje treba skladovou kartu,
muzu ji porad videt, to nicemu nevadi. Nepusti mne to pouze do jeji
editace, nez to dotycny dodela. Zadny problem. 

-- 
Michal Samek <spec_list na tony.cz>


From horak na sitmp.cz  Fri Feb 20 15:34:40 2004
From: horak na sitmp.cz (=?US-ASCII?Q?Horak_Daniel?=)
Date: Fri, 20 Feb 2004 15:34:40 +0100
Subject: Jak na browse velke tabulky v sql ?
Message-ID: <66EFFC1A2B0A424E87D68EC10B1F458D04086A@EXCH2.mmp.plzen-city.cz>

> 
> > U zaznamu, ktery je "vybrany" si zapamatujete hodnotu 
> primarniho klice a
> > podle te se zaznam v "browseru" zase (po setrideni) najde.
> 
> Jak? Ja potrebuji zacatek (offset) vyjadreny jako cislo, jako 
> pozice. To

Ale v SQL se na neco takoveho, jako je cislo pozice, nemuzete
spolehnout.

> je mi jasne, ze muzu zaznam primo vybrat, ale to mi prece 
> nepomuze. Nebo
> jsem uplne blby (dneska bych se nedivil). Nebo to myslite tak, ze do
> toho gui objektu nacitate vsechny radky a to ja prave nechci, ja chci
> selectovat jen kratsi useky podle potreby (zastrankuju --> 
> select treba
> 50 dalsich zaznamu).

Postupne nacitani se da resit prave pomoci kurzoru (nebo limit + offset,
ale tam je problem s tim cislovanim). Pri "strankovani" si donactete jen
ta dalsi data. Ale "aktualni" polozku je nutne nastavit (byt treba
sekvencnim prohledanim) az podle dat, ktera v browseru skutecne jsou, a
to podle jejiho PK.

Pro razeni nemusi byt nutne pouzivat SQL, ale muze to umet "browser" sam
od sebe, aspon pro nejake datove typy.

> 
> > 
> > Ale docilit shodneho chovani u SQL jakou xBase nejde bez 
> velmi velkeho
> > usili. Sam jsem vytvarel GUI prvky pro pristup k datum v 
> SQL serverech
> > do knihovny wxWindows ;-)

Ale zatim jsem to nezverejnil a neumi to jeste efektivne pracovat s
velkymi tabulkami ;-)

Jako hotove reseni bych zkusil Kylix/Delphi. Ty jejich knihovny na to
nejspis mysli. Ale nikdy jsem v nich nedelal.

> 
> ha, na to se musim podivat. O to mi slo, ze uz nekdo prece tohle musel
> nejak resit.
> 
> > 
> > Elegance v xbase mozna je, ale jak se zachova pri zmenach 
> provadenych
> > soucasne nekolika klienty.
> 
> No jak, normalne :) Dnes se sice uz zaznamy nezamykaji, mame 
> transakce,
> ale fakt je, ze tento klasicky pristup zamykat zaznam nejakou zvlastni
> nahodou presne vyhovuje logice prace toho systemu a vubec nijak se tim
> necitime omezovani. Nedela nas sice najednou zrovna 1000, ale 
> to je asi
> jedno. Stejne nema logiku, aby prijemku plnili soucasne 2 lide...

Takoveto zamykani zaznamu je mozne (nutne?) provadet na aplikacni
urovni.

Proste neni jednoduche aplikaci v xbase (s daty v index-sekvencnich
souborech) snadno predelat do SQL, kde se s daty pracuje uplne jinak.


			Dan

From kluvanek na tesnet.cz  Fri Feb 20 15:07:06 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 15:07:06 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF44302302F2@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF44302302F2@percival.fonet.cz>
Message-ID: <4036148A.2010402@trb.tesnet.cz>

Pavel Janoušek napsal(a):

>>-----Original Message-----
>>From: Michal Samek [mailto:spec_list na tony.cz] 
>>elegantne resitelne), tak mne zajima, zda mi neco zasadniho 
>>neuniklo :) 
> 
> 
> 	Uniklo - 3 a více-vrstvý model...:-)
Asi budem ten blbec, co sa pyta prvy, ja, ale dalo by sa o tom trochu pojednat?

> 
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From kluvanek na tesnet.cz  Fri Feb 20 15:05:49 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Fri, 20 Feb 2004 15:05:49 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
Message-ID: <4036143D.8090205@trb.tesnet.cz>

Horák Daniel napsal(a):

>>Ano, ale to jsem prece sam napsal v puvodnim dotazu. Jde mi o 
>>to, ze mi
>>to pripada cele prilis slozite (oproti xbase, kde to je prirozene
>>elegantne resitelne), tak mne zajima, zda mi neco zasadniho 
>>neuniklo :) 
>>A navic porad nevim, jak mam po zmene setrideni zjistit pozici daneho
>>zaznamu v jinem orderu, aniz by se z toho stalo totalne 
>>pomale monstrum.
>>Proste zmenim setrideni a v tu chvili nevim, jaky offset 
>>pouzit, aby mi
>>zaznam pod kurzorem (ten graficky, ne db) zustal stejny. 
> 
> 
> U zaznamu, ktery je "vybrany" si zapamatujete hodnotu primarniho klice a
> podle te se zaznam v "browseru" zase (po setrideni) najde.
No pouziva sa i rowID...
Lenze to je problem, ze ked mam kurzor na vyhliadnutom zazname ID a teraz to 
pretriedim podla niecoho ineho, tak si nespominam na rozumnu moznost, ako dostat 
+-20 zaznamov v okoli ID pri pouziti noveho triedenia.
Samozrejme to je len jeden z problemov.

> 
> Ale docilit shodneho chovani u SQL jakou xBase nejde bez velmi velkeho
> usili. Sam jsem vytvarel GUI prvky pro pristup k datum v SQL serverech
> do knihovny wxWindows ;-)
> 
> Elegance v xbase mozna je, ale jak se zachova pri zmenach provadenych
> soucasne nekolika klienty.
> 
> 
> 			Dan
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From zakkr na zf.jcu.cz  Fri Feb 20 16:15:46 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Fri, 20 Feb 2004 16:15:46 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077288899.2638.120.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain>
Message-ID: <20040220151546.GE3644@zf.jcu.cz>

On Fri, Feb 20, 2004 at 03:55:00PM +0100, Michal Samek wrote:
> 
> > 
> > U zaznamu, ktery je "vybrany" si zapamatujete hodnotu primarniho klice a
> > podle te se zaznam v "browseru" zase (po setrideni) najde.
> 
> Jak? Ja potrebuji zacatek (offset) vyjadreny jako cislo, jako pozice. To

 Ale k cemu, kdyz se vam ten pocet zaznamu a tim i pozice, pocet stranek
 a proste vse meni?
 
 Dan myslel  to, ze zaznam ktery  to GUI ukazuje ma  (musi mit:-) nejaky
 jednoznacny identifkator  (PRIMARY KEY). Pred reloadem dat  toho GUI si
 toto ID zapamatujete a pak v  novych datech opet naleznete a oznacite a
 uzivateli ukazete.

> je mi jasne, ze muzu zaznam primo vybrat, ale to mi prece nepomuze. Nebo
> jsem uplne blby (dneska bych se nedivil). Nebo to myslite tak, ze do
> toho gui objektu nacitate vsechny radky a to ja prave nechci, ja chci
> selectovat jen kratsi useky podle potreby (zastrankuju --> select treba
> 50 dalsich zaznamu).

 IMHO  my pripada lepsi strankovat pomoci kursoru (SQL) a update dat v
 GUI provadet jen na uzivatelovo pozadani.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From Janousek na FoNet.Cz  Fri Feb 20 16:53:26 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Fri, 20 Feb 2004 16:53:26 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4036148A.2010402@trb.tesnet.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A51@percival.fonet.cz>

> -----Original Message-----
> From: Kluvanek Martin [mailto:kluvanek na tesnet.cz] 
> > 	Uniklo - 3 a více-vrstvý model...:-)
> Asi budem ten blbec, co sa pyta prvy, ja, ale dalo by sa o 
> tom trochu pojednat?

	Pokud si myslim, ze tusim, co je historicka xbase (dBase,
FoxPro, Clipper atd.) a podobne, pak:

2- vrstvy:
prezentacni logika, aplikacni logicka
data (databazovy server)

3-vrstvy:
prezentacni logika
aplikacni logika
data (databazovy server)


	A prave to, co se tu aktualne resi je to, jak v pripade
databazoveho SQL serveru zajistit, ze aplikacni logika pracuje nad
aktualnimi daty a prezentacni umi spravne zobrazovat - jak vidite, pokud
ty pohledy/vrstvy oddelite, nemusi to byt az tak slozite, ale je pravda,
ze "konvencni" programatori maji radsi praci on-side - tedy mam konektor
na data a TED si s daty provedu vse co potrebuji - i ja jsem takovy a
mam s 3-vrstvym pristupem casto problem ho spravne modelovat a vyuzivat.

	Navic otazku efektivity bych nezanedbaval, v pripade 2-vrstveho
pristupu neni komunikace mezi vrstvami zanedbatelna (a nelze ji moc
optimalizovat), naopak v dobre udelane aplikaci trivrstveho modelu je
hlavni zatez mezi spodnimi a mezi prezentacni a aplikacni koluji
skutecne jen "chtena" data, ktera se musi transportovat tak jako tak.

PS: Nejsem teoretik, pisu z pozice praktika, teorii urcite lepe zvladnou
jini...

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From "Joseph Lanier" na muni.cz  Sat Feb 21 08:14:10 2004
From: "Joseph Lanier" na muni.cz ("Joseph Lanier" na muni.cz)
Date: Sat, 21 Feb 2004 10:14:10 +0300
Subject: ::NaturalGain Pill - Designed for penís enlargment
Message-ID: <200402210723.i1L7NSRZ009161@anor.ics.muni.cz>

<html>   
&#73;&#116;&#115;&#32;&#78;&#101;&#119;&#44;&#32;&#73;&#116;&#115;&#32;&#83;&#97;&#102;&#101;&#33;<br>  
&#73;&#116;&#115;&#32;&#84;&#104;&#101;&#32;&#77;&#111;&#115;&#116;&#32;&#65;&#100;&#118;&#97;&#110;&#99;&#101;&#100;&#32;&#80;&#101;&#110;&#105;&#108;&#101;&#32;&#69;&#110;&#108;&#97;&#114;&#103;&#101;&#109;&#101;&#110;&#116;&#32;&#83;&#111;&#108;&#117;&#116;&#105;&#111;&#110;&#33;<br>  
&#73;&#116;&#39;&#115;&#32;&#49;&#48;&#48;&#37;&#32;&#71;&#117;&#97;&#114;&#97;&#110;&#116;&#101;&#101;&#100;&#32;&#84;&#111;&#32;&#69;&#110;&#108;&#97;&#114;&#103;&#101;&#32;&#89;&#111;&#117;&#114;&#32;&#80;&#101;&#110;&#105;&#115;&#46;&#32;&#51;&#43;&#32;&#73;&#110;&#99;&#104;&#101;&#115;<br>  
&#78;&#97;&#116;&#117;&#114;&#97;&#108;&#71;&#97;&#105;&#110;+  <p><b><font color="#FF0000"><a  
href="http://euphemism.turwy33.info/p1/?id=bsd">&#82;&#69;&#65;&#68;&#32;&#77;&#79;&#82;&#69;&#32;&#73;&#78;&#70;&#79;&#32;&#72;&#69;&#82;&#69;</a></font></font></b><br> 
<p> 
<p> 
<p> 
<p> 
<p><font size=-2><a href="http://portentous.frankit.us/oz.html">no 
more emailz</a></font></font></font></center> 

<br><p>    
</html>

From spec_list na tony.cz  Sat Feb 21 10:53:48 2004
From: spec_list na tony.cz (Michal Samek)
Date: 21 Feb 2004 10:53:48 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040220151546.GE3644@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
	 <1077288899.2638.120.camel@localhost.localdomain>
	 <20040220151546.GE3644@zf.jcu.cz>
Message-ID: <1077357227.3915.4.camel@localhost.localdomain>

V Pá, 20. 02. 2004 v 16.15, Karel Zak napsal:
> On Fri, Feb 20, 2004 at 03:55:00PM +0100, Michal Samek wrote:
> > 
> > > 
> > > U zaznamu, ktery je "vybrany" si zapamatujete hodnotu primarniho klice a
> > > podle te se zaznam v "browseru" zase (po setrideni) najde.
> > 
> > Jak? Ja potrebuji zacatek (offset) vyjadreny jako cislo, jako pozice. To
> 
>  Ale k cemu, kdyz se vam ten pocet zaznamu a tim i pozice, pocet stranek
>  a proste vse meni?
>  
>  Dan myslel  to, ze zaznam ktery  to GUI ukazuje ma  (musi mit:-) nejaky
>  jednoznacny identifkator  (PRIMARY KEY). Pred reloadem dat  toho GUI si
>  toto ID zapamatujete a pak v  novych datech opet naleznete a oznacite a
>  uzivateli ukazete.

No prave, ted uz se opakuji, psal jsem, ze toto lze jedine v pripade, ze
fetchnu cely rozsah zobrazovanych dat, a to zase nechci kvuli jejich
rozsahu. Je to o par radku niz :) A navic, nac mam potom databazi, kdyz
musim rucne neco hledat ve vysledku? 

> 
> > je mi jasne, ze muzu zaznam primo vybrat, ale to mi prece nepomuze. Nebo
> > jsem uplne blby (dneska bych se nedivil). Nebo to myslite tak, ze do
> > toho gui objektu nacitate vsechny radky a to ja prave nechci, ja chci
> > selectovat jen kratsi useky podle potreby (zastrankuju --> select treba
> > 50 dalsich zaznamu).
> 
>  IMHO  my pripada lepsi strankovat pomoci kursoru (SQL) a update dat v
>  GUI provadet jen na uzivatelovo pozadani.

A zase dokolecka, jak potom udelate tu zmenu setrideni bez nutnosti
nasledne projet v cyklu cely select result, abyste nasel spravny offset?
O tom to cele je, proto tu pisu. Vadi mi, ze toto slo uplne v pohode
realizovat v xbase a ve slavnem sql si takhle ani neskrtnu. 

> 
>     Karel
-- 
Michal Samek <spec_list na tony.cz>


From spec_list na tony.cz  Sat Feb 21 11:02:56 2004
From: spec_list na tony.cz (Michal Samek)
Date: 21 Feb 2004 11:02:56 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <66EFFC1A2B0A424E87D68EC10B1F458D04086A@EXCH2.mmp.plzen-city.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D04086A@EXCH2.mmp.plzen-city.cz>
Message-ID: <1077357775.3917.13.camel@localhost.localdomain>

V Pá, 20. 02. 2004 v 15.34, Horak Daniel napsal:
> > 
> > > U zaznamu, ktery je "vybrany" si zapamatujete hodnotu 
> > primarniho klice a
> > > podle te se zaznam v "browseru" zase (po setrideni) najde.
> > 
> > Jak? Ja potrebuji zacatek (offset) vyjadreny jako cislo, jako 
> > pozice. To
> 
> Ale v SQL se na neco takoveho, jako je cislo pozice, nemuzete
> spolehnout.

Ano, ja vim, cela filozofie sql nadherne resi zapouzdreni databaze,
umoznuje efektivne provadet dotazy a soubezne updaty, ale pro urcite
aplikace to neni dostatecne. Proc to vadi jenom mne, to porad nechapu. V
jednu chvili jakoby vsichni presli na sql, bylo to to spravne
"buzz-word", ale funkcnost xbase je porad v urcitych pripadech
nenahraditelna. Podle mne toho zas tak moc nechci, ale fakt nemam sanci
s sql uspet. Asi bych potreboval nejaky hybrid, ktery umoznuje i "raw"
pohyb po tabulkach po indexech ve stylu "stare skoly". V podstate nejake
rozsireni kurzoru.

> 
> > je mi jasne, ze muzu zaznam primo vybrat, ale to mi prece 
> > nepomuze. Nebo
> > jsem uplne blby (dneska bych se nedivil). Nebo to myslite tak, ze do
> > toho gui objektu nacitate vsechny radky a to ja prave nechci, ja chci
> > selectovat jen kratsi useky podle potreby (zastrankuju --> 
> > select treba
> > 50 dalsich zaznamu).
> 
> Postupne nacitani se da resit prave pomoci kurzoru (nebo limit + offset,
> ale tam je problem s tim cislovanim). Pri "strankovani" si donactete jen
> ta dalsi data. Ale "aktualni" polozku je nutne nastavit (byt treba
> sekvencnim prohledanim) az podle dat, ktera v browseru skutecne jsou, a
> to podle jejiho PK.
> 
> Pro razeni nemusi byt nutne pouzivat SQL, ale muze to umet "browser" sam
> od sebe, aspon pro nejake datove typy.

Tohle opet nemohu pouzit, pokud nechci nacitat vysledek celeho selectu,
ale strankovat postupne... Navic tridit a hledat ma databaze, ne
aplikace.

> 
> > 
> > > 
> > > Ale docilit shodneho chovani u SQL jakou xBase nejde bez 
> > velmi velkeho
> > > usili. Sam jsem vytvarel GUI prvky pro pristup k datum v 
> > SQL serverech
> > > do knihovny wxWindows ;-)
> 
> Ale zatim jsem to nezverejnil a neumi to jeste efektivne pracovat s
> velkymi tabulkami ;-)
> 
> Jako hotove reseni bych zkusil Kylix/Delphi. Ty jejich knihovny na to
> nejspis mysli. Ale nikdy jsem v nich nedelal.
> 
> > 
> > ha, na to se musim podivat. O to mi slo, ze uz nekdo prece tohle musel
> > nejak resit.
> > 
> > > 
> > > Elegance v xbase mozna je, ale jak se zachova pri zmenach 
> > provadenych
> > > soucasne nekolika klienty.
> > 
> > No jak, normalne :) Dnes se sice uz zaznamy nezamykaji, mame 
> > transakce,
> > ale fakt je, ze tento klasicky pristup zamykat zaznam nejakou zvlastni
> > nahodou presne vyhovuje logice prace toho systemu a vubec nijak se tim
> > necitime omezovani. Nedela nas sice najednou zrovna 1000, ale 
> > to je asi
> > jedno. Stejne nema logiku, aby prijemku plnili soucasne 2 lide...
> 
> Takoveto zamykani zaznamu je mozne (nutne?) provadet na aplikacni
> urovni.
> 
> Proste neni jednoduche aplikaci v xbase (s daty v index-sekvencnich
> souborech) snadno predelat do SQL, kde se s daty pracuje uplne jinak.
> 
> 
> 			Dan
-- 
Michal Samek <spec_list na tony.cz>


From mike na mk-sys.cz  Sat Feb 21 11:21:40 2004
From: mike na mk-sys.cz (Michal Kubecek)
Date: Sat, 21 Feb 2004 11:21:40 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077357227.3915.4.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain>
Message-ID: <20040221102140.GA32408@kubecekserver.mk-sys.cz>

On Sat, Feb 21, 2004 at 10:53:48AM +0100, Michal Samek wrote:
> 
> A zase dokolecka, jak potom udelate tu zmenu setrideni bez nutnosti
> nasledne projet v cyklu cely select result, abyste nasel spravny offset?

select count(*) from TBL where NEWKEY<current_new_key

Samozřejmě pokud chcete mít jistotu, že až budete provádět následující
dotaz, neposune se vám to, použijete snapshot izolaci.

                                                          Michal Kubeček

From jiri.borik na volny.cz  Sun Feb 22 01:20:24 2004
From: jiri.borik na volny.cz (Jiri Borik)
Date: Sun, 22 Feb 2004 01:20:24 +0100 (CET)
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040221102140.GA32408@kubecekserver.mk-sys.cz>
Message-ID: <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24>

On Sat, 21 Feb 2004, Michal Kubecek wrote:

> > A zase dokolecka, jak potom udelate tu zmenu setrideni bez nutnosti
> > nasledne projet v cyklu cely select result, abyste nasel spravny offset?
> 
> select count(*) from TBL where NEWKEY<current_new_key

Jenže takový dotaz není asi moc optimální. Pokud si to dobře představuji,
tak se jedná o sekvenční průchod od začátku až k dané pozici, což u
zmiňovaných velkých souborů nebude ono. Sice to udělá místo klienta
server, ale v konečném důsledku to stejně může být pomalé. 

Nešlo by něco jako:

select from TBL where where NEWKEY<current_new_key 
	order by NEWKEY desc limit 50
union
select from TBL where where NEWKEY>=current_new_key 
	order by NEWKEY limit 50

To by mělo dát +-50 záznamů dle aktuální hodnoty klíče. A dle rowid mezi
nimi najdu pracovní záznam a mám okolí podle nového klíče. Další stránky
dopředu nebo vzad bych získával podobně. 

Jiří Bořík <jiri.borik na volny.cz>



From mike na mk-sys.cz  Sun Feb 22 02:18:01 2004
From: mike na mk-sys.cz (Michal Kubecek)
Date: Sun, 22 Feb 2004 02:18:01 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24>
References: <20040221102140.GA32408@kubecekserver.mk-sys.cz> <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24>
Message-ID: <20040222011800.GA1193@kubecekserver.mk-sys.cz>

On Sun, Feb 22, 2004 at 01:20:24AM +0100, Jiri Borik wrote:
> On Sat, 21 Feb 2004, Michal Kubecek wrote:
> > 
> > select count(*) from TBL where NEWKEY<current_new_key
> 
> Jenže takový dotaz není asi moc optimální. Pokud si to dobře představuji,
> tak se jedná o sekvenční průchod od začátku až k dané pozici, což u
> zmiňovaných velkých souborů nebude ono. Sice to udělá místo klienta
> server, ale v konečném důsledku to stejně může být pomalé. 

Je-li na tom sloupci index, není důvod to procházet sekvenčně, stačí
půlení intervalu, takže časová složitost je O(log n).

                                                         Michal Kubeček

From npepgytsn na hismail.cc  Sun Feb 22 10:58:35 2004
From: npepgytsn na hismail.cc (Mable Wilkinson)
Date: Sun, 22 Feb 2004 10:58:35 +0100
Subject: Fwd: Important information qmv
Message-ID: <NPBYLZGQVYZWPTUAREFMNEN@inker.com>


Generic Cialis get hard upto 36 hours
http://rd.yahoo.com/dir/?http://www.vcvpoews.com/cu/


bessie nrc cranberry cleave boon stroboscopic liturgic dopant tremor appointee eel westerly bellwether alteration wide solid carthaginian philanthropic precise companionway chanson  forcible noise rent chen quartic alcott rightful cadenza occupy delphic clutter delicacy cozen fondle thyme jon bellwether ablate joke xylophone polymer cupid bobolink cop millikan cinnamon simple acquiescent aeneid arctic jacm bedazzle trinitarian apologia upperclassmen asbestos 


From mcaslavsky na macroware.cz  Sun Feb 22 14:32:55 2004
From: mcaslavsky na macroware.cz (Martin Caslavsky)
Date: Sun, 22 Feb 2004 14:32:55 +0100
Subject: pgsql 7.4 a nefungujici schemata
Message-ID: <200402221333.i1MDXHMI003006@quin.macroware.cz>

Dobry den,

mam problem s PostgeSQL 7.4.1 instalovanym z deb balicku na
http://people.debian.org/~elphick/debian/dists/woody/main/binary-i386/misc/
Predtim jsem mel nainstalovanou 7.2, tu jsem odinstaloval a vymazal všechny
adresare postgresql z /var, /usr a vsude, kde jsem si jenom vzpomnel.

Jde o to, ze když uzivatelem postgres vytvorim schema, tak schema vidi pouze
tento uzivatel a nikdo jiny.

template1=# create database uzivatel;
CREATE DATABASE
template1=# create user uzivatel with password 'uzivatel';
CREATE USER
template1=# create schema authorization uzivatel;
CREATE SCHEMA

\dn -- vypise mezi schematy "uzivatel"
Stejne tak
template1=# create table uzivatel.t (i int);
CREATE TABLE

Pokud se ale prihlasim jako "uzivatel", tak ve vypisu \dn schema "uzivatel"
není a 
uzivatel=> create table uzivatel.t (i int);
ERROR:  schema "uzivatel" does not exist

Zkousel jsem vsechno smazat, znova nainstalovat, znovu vytvorit
dataspace,...

Hodne zvlastni je, ze když jsem ty stejne balicky nainstaloval na jiny
stroj, tak se tam tohle zvlastni chovani nevyskytovalo.

                             Martin Caslavsky


From zakkr na zf.jcu.cz  Mon Feb 23 08:22:43 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 23 Feb 2004 08:22:43 +0100
Subject: pgsql 7.4 a nefungujici schemata
In-Reply-To: <200402221333.i1MDXHMI003006@quin.macroware.cz>
References: <200402221333.i1MDXHMI003006@quin.macroware.cz>
Message-ID: <20040223072243.GA16876@zf.jcu.cz>

On Sun, Feb 22, 2004 at 02:32:55PM +0100, Martin Caslavsky wrote:
> Dobry den,
> 
> mam problem s PostgeSQL 7.4.1 instalovanym z deb balicku na
> http://people.debian.org/~elphick/debian/dists/woody/main/binary-i386/misc/
> Predtim jsem mel nainstalovanou 7.2, tu jsem odinstaloval a vymazal všechny
> adresare postgresql z /var, /usr a vsude, kde jsem si jenom vzpomnel.
> 
> Jde o to, ze když uzivatelem postgres vytvorim schema, tak schema vidi pouze
> tento uzivatel a nikdo jiny.
> 
> template1=# create database uzivatel;
> CREATE DATABASE
> template1=# create user uzivatel with password 'uzivatel';
> CREATE USER
> template1=# create schema authorization uzivatel;
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> CREATE SCHEMA
> 
> \dn -- vypise mezi schematy "uzivatel"
> Stejne tak
> template1=# create table uzivatel.t (i int);
> CREATE TABLE
> 
> Pokud se ale prihlasim jako "uzivatel", tak ve vypisu \dn schema "uzivatel"
> není a 
> uzivatel=> create table uzivatel.t (i int);

 Kdyz on to schema v DB "uzivatel" take nikdo neudelal, ale udelal ho
 v  "template1" :-)

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Mon Feb 23 09:35:54 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Mon, 23 Feb 2004 09:35:54 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077357227.3915.4.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain>
Message-ID: <20040223083554.GA2538@anxur.fi.muni.cz>

On Sat, Feb 21, 2004 at 10:53:48AM +0100, Michal Samek wrote:
> 
> No prave, ted uz se opakuji, psal jsem, ze toto lze jedine v pripade, ze
> fetchnu cely rozsah zobrazovanych dat, a to zase nechci kvuli jejich

Tohle neni pravda. Vy muzete otevrit kurzor podle hodnot, nacist 30
nasledujicich, tricet predchozich. Akorat pokud nemate jako unikatni
klic hodnoty toho zaznamu (a psal jste, ze v tech datech je dost
binec), tak se nemuzete na ten zaznam pak vratit presne pomoci hodnot.
V takovem pripade se budete muset vratit pomoci syntetickeho
primarniho klice.

> rozsahu. Je to o par radku niz :) A navic, nac mam potom databazi, kdyz
> musim rucne neco hledat ve vysledku? 

Protoze pouzivate pojem "pozice" u relaci, ktere se Vam meni pod
rukama.

Databazi mate na to, aby Vam zajistila ACID. Aplikacni a prezentacni
logiku mate, aby Vam podle tech dat nakreslila obrazky.

> A zase dokolecka, jak potom udelate tu zmenu setrideni bez nutnosti
> nasledne projet v cyklu cely select result, abyste nasel spravny offset?

	select neco from tabulka where hodnota > ? order by hodnota

> O tom to cele je, proto tu pisu. Vadi mi, ze toto slo uplne v pohode
> realizovat v xbase a ve slavnem sql si takhle ani neskrtnu. 

Vite, prijde mi, ze uz je to trosku nudne. Zjistil jste, ze se SQL
chova jinak. Asi to budete muset akceptovat, chcete-li SQL pouzit.
Lide se Vam tady snazi vysvetlit, jak a proc se to v SQL dela, jak se
da dosahnout ekvivalentu toho, co ted delate jako browse v xbase.
Nikdo tady netvrdil, ze SQL vyresi Vas ukol, akorat Vy mate takovou
predstavu.

Paklize Vam aplikace v xbase funguje, tak ji neprepisujte. Paklize
je to dostatecne rychle, pouzivaji to soucasne dva lide, nikdy Vam
nespadl stroj, na kterem to bezi, nikdy jste nepotreboval obnovit
ztracena data, nepotrebujete vzdaleny pristup a nepotrebujete to
skalovat -- prosim, nenutte se do SQL.

Pokud se pro SQL rozhodnete, prosim, akceptujte doporuceni a rady,
ktere Vam lide davaji, a neprokladejte to vykriky "ale xbase mi k tomu
jeste zahralo pisnicku, SQL je nanic".

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From adelton na informatics.muni.cz  Mon Feb 23 09:39:20 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Mon, 23 Feb 2004 09:39:20 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24>
References: <20040221102140.GA32408@kubecekserver.mk-sys.cz> <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24>
Message-ID: <20040223083920.GB2538@anxur.fi.muni.cz>

On Sun, Feb 22, 2004 at 01:20:24AM +0100, Jiri Borik wrote:
> > 
> > select count(*) from TBL where NEWKEY<current_new_key
> 
> Jenže takový dotaz není asi moc optimální. Pokud si to dobře představuji,
> tak se jedná o sekvenční průchod od začátku až k dané pozici, což u
> zmiňovaných velkých souborů nebude ono. Sice to udělá místo klienta

No, v optimalním případě máte na TBL.NEWKEY index, takže spočítat to
vezme O(log(n)).

> Nešlo by něco jako:
> 
> select from TBL where where NEWKEY<current_new_key 
> 	order by NEWKEY desc limit 50
> union
> select from TBL where where NEWKEY>=current_new_key 
> 	order by NEWKEY limit 50
> 
> To by mělo dát +-50 záznamů dle aktuální hodnoty klíče. A dle rowid mezi
> nimi najdu pracovní záznam a mám okolí podle nového klíče. Další stránky
> dopředu nebo vzad bych získával podobně. 

Ano, například. Ještě je možno zvážit náhradu union za union all.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From kluvanek na tesnet.cz  Mon Feb 23 09:52:31 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 09:52:31 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223083920.GB2538@anxur.fi.muni.cz>
References: <20040221102140.GA32408@kubecekserver.mk-sys.cz> <Pine.LNX.3.96.1040222004625.2894C-100000@u24.u24> <20040223083920.GB2538@anxur.fi.muni.cz>
Message-ID: <4039BF4F.90008@trb.tesnet.cz>

Honza Pazdziora napsal(a):

> On Sun, Feb 22, 2004 at 01:20:24AM +0100, Jiri Borik wrote:
> 
>>> select count(*) from TBL where NEWKEY<current_new_key
>> 
>> Jenže takový dotaz není asi moc optimální. Pokud si to dobře představuji, 
>> tak se jedná o sekvenční průchod od začátku až k dané pozici, což u 
>> zmiňovaných velkých souborů nebude ono. Sice to udělá místo klienta
> 
> 
> No, v optimalním případě máte na TBL.NEWKEY index, takže spočítat to vezme
> O(log(n)).
No a navyse si myslim, ze to xbase asi riesila nejak podobne, len o tom
aplikacia nevedela, bezalo to na lokalnom stroji nad lokalnymi DB subormi

> 
>> Nešlo by něco jako:
>> 
>> select from TBL where where NEWKEY<current_new_key order by NEWKEY desc
>> limit 50 union select from TBL where where NEWKEY>=current_new_key order by
>> NEWKEY limit 50
>> 
>> To by mělo dát +-50 záznamů dle aktuální hodnoty klíče. A dle rowid mezi 
>> nimi najdu pracovní záznam a mám okolí podle nového klíče. Další stránky 
>> dopředu nebo vzad bych získával podobně.
> 
> 
> Ano, například. Ještě je možno zvážit náhradu union za union all.
Akurat som si nie celkom isty, ako by to bolo s rychlostou, keby ta WHERE
podmienka bola o dost komplikovanejsia (vela filtrovacich vyrazov nad
neindexovanymi polozkami).
Typicky napriklad filter na hodnotu poznamky.

Ale na druhu stranu si myslim, ze to SQL servery zvladaju optimalizovat vcelku
vpohode.

> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From Janousek na FoNet.Cz  Mon Feb 23 09:59:35 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Mon, 23 Feb 2004 09:59:35 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039BF4F.90008@trb.tesnet.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz>

> -----Original Message-----
> From: Kluvanek Martin [mailto:kluvanek na tesnet.cz] 
> keby ta WHERE
> podmienka bola o dost komplikovanejsia (vela filtrovacich vyrazov nad
> neindexovanymi polozkami).
> Typicky napriklad filter na hodnotu poznamky.

	To je ovšem podružný a řešitelný probém - doplnit SQL serveru
"hledané" vhodné indicie jako patřičné indexy - škálovat lze mnoha
způsoby - od HW, přes návrh a normalizaci DB až po pomocné prostředky
jako čištění (VACUUM v případě PgSQL) apod.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From kluvanek na tesnet.cz  Mon Feb 23 10:13:16 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 10:13:16 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz>
Message-ID: <4039C42C.6020303@trb.tesnet.cz>

Ing. Pavel Janousek napsal(a):

>>-----Original Message-----
>>From: Kluvanek Martin [mailto:kluvanek na tesnet.cz] 
>>keby ta WHERE
>>podmienka bola o dost komplikovanejsia (vela filtrovacich vyrazov nad
>>neindexovanymi polozkami).
>>Typicky napriklad filter na hodnotu poznamky.
> 
> 
> 	To je ovšem podružný a řešitelný probém - doplnit SQL serveru
> "hledané" vhodné indicie jako patřičné indexy - škálovat lze mnoha
> způsoby - od HW, přes návrh a normalizaci DB až po pomocné prostředky
> jako čištění (VACUUM v případě PgSQL) apod.
No neviem, ako by vypadal index na tabulku kde sa filtruje podla 4 poli typu 
varchar a uzivatel si tam moze nacpat lubovolny nezmysel, k tomu este asi 9 
numerickych poli.

> 
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From zakkr na zf.jcu.cz  Mon Feb 23 10:15:39 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 23 Feb 2004 10:15:39 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223083554.GA2538@anxur.fi.muni.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain> <20040223083554.GA2538@anxur.fi.muni.cz>
Message-ID: <20040223091539.GB16876@zf.jcu.cz>

On Mon, Feb 23, 2004 at 09:35:54AM +0100, Honza Pazdziora wrote:
> Vite, prijde mi, ze uz je to trosku nudne. Zjistil jste, ze se SQL
> chova jinak. Asi to budete muset akceptovat, chcete-li SQL pouzit.

 Presne. Vetsinu poslednich dopisu tohodle threadu jsem smazal s tim, ze
 dotycnemu neni pomoci. Pripada  mi jako nekdo kdo  dlouha leta pouzival
 na tahani nakladu  tank, a ted protoze ostatni uz  delsi dobu pouzivaji
 nakladak tak ho chce take. Jen ted zacal vsem okolo nadavat co je to za
 blbost ty blatniky vzdyt mu to brani na ten nakladak nasadit pasy...

> Paklize Vam aplikace v xbase funguje, tak ji neprepisujte. Paklize
> je to dostatecne rychle, pouzivaji to soucasne dva lide, nikdy Vam
> nespadl stroj, na kterem to bezi, nikdy jste nepotreboval obnovit
> ztracena data, nepotrebujete vzdaleny pristup a nepotrebujete to
> skalovat -- prosim, nenutte se do SQL.

 Ostatne kouknete se treba na M$, delaji jak SQL tak i Acceess a jak
 se zda tak si nekonkuruji a sve misto na trhu ma oboje.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From zakkr na zf.jcu.cz  Mon Feb 23 10:19:35 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 23 Feb 2004 10:19:35 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039C42C.6020303@trb.tesnet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz> <4039C42C.6020303@trb.tesnet.cz>
Message-ID: <20040223091935.GC16876@zf.jcu.cz>

On Mon, Feb 23, 2004 at 10:13:16AM +0100, Kluvanek Martin wrote:
> >	To je ovšem podružný a řešitelný probém - doplnit SQL serveru
> >"hledané" vhodné indicie jako patřičné indexy - škálovat lze mnoha
> >způsoby - od HW, přes návrh a normalizaci DB až po pomocné prostředky
> >jako čištění (VACUUM v případě PgSQL) apod.
> No neviem, ako by vypadal index na tabulku kde sa filtruje podla 4 poli 
> typu varchar a uzivatel si tam moze nacpat lubovolny nezmysel, k tomu este 
> asi 9 numerickych poli.

 CREATE INDEX idx ON tabname ( f1, f2, f3, f4 );

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From Janousek na FoNet.Cz  Mon Feb 23 10:20:02 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Mon, 23 Feb 2004 10:20:02 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039C42C.6020303@trb.tesnet.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A59@percival.fonet.cz>

> -----Original Message-----
> From: Kluvanek Martin [mailto:kluvanek na tesnet.cz] 
> No neviem, ako by vypadal index na tabulku kde sa filtruje 

	Prominte, ale vy jste v zivote nepouzil JINY index nez pres
jeden sloupec?

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From spec_list na tony.cz  Mon Feb 23 11:34:54 2004
From: spec_list na tony.cz (Michal Samek)
Date: 23 Feb 2004 11:34:54 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223091539.GB16876@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
	 <1077288899.2638.120.camel@localhost.localdomain>
	 <20040220151546.GE3644@zf.jcu.cz>
	 <1077357227.3915.4.camel@localhost.localdomain>
	 <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz>
Message-ID: <1077532493.1431.9.camel@localhost.localdomain>

V Po, 23. 02. 2004 v 10.15, Karel Zak napsal:
> On Mon, Feb 23, 2004 at 09:35:54AM +0100, Honza Pazdziora wrote:
> > Vite, prijde mi, ze uz je to trosku nudne. Zjistil jste, ze se SQL
> > chova jinak. Asi to budete muset akceptovat, chcete-li SQL pouzit.
> 
>  Presne. Vetsinu poslednich dopisu tohodle threadu jsem smazal s tim, ze
>  dotycnemu neni pomoci. Pripada  mi jako nekdo kdo  dlouha leta pouzival
>  na tahani nakladu  tank, a ted protoze ostatni uz  delsi dobu pouzivaji
>  nakladak tak ho chce take. Jen ted zacal vsem okolo nadavat co je to za
>  blbost ty blatniky vzdyt mu to brani na ten nakladak nasadit pasy...
> 

Ja myslim, ze trosku prehanite. Zeptal jsem se na konkretni problem a
rozebrali jsme jej. To je vse. Dostali jsme se v podstate k tomu, ze je
to bohuzel tak, jak to je a ze to s sql lepe udelat nepujde. To je to,
co jsem chtel slyset, ve "vetsine poslednich dopisu" jsem vam do toho uz
ani nepipnul. Prave proto, ze zcela jiste jsem "poznamenany" minulosti a
vyvojem v xbase, jsem tady napsal, at mi poradi lide, co s sql maji
radove vetsi zkusenosti. Nikomu jsem nenadaval a v podstate jste mi dali
za pravdu, ze implementace takove situace pomoci sql *muze* byt mene
efektivni nez v xbase. Nezbyva mi nez udelat prakticke testy a srovnat,
zda to bude vubec vykonove pouzitelne, pripadne zmenit ui aplikace, coz
ale bude problem - uzivatele mi to omlati o hlavu. 

-- 
Michal Samek <spec_list na tony.cz>


From sherry na pikebo.cz  Mon Feb 23 10:36:38 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Mon, 23 Feb 2004 10:36:38 +0100
Subject: Jak na browse velke tabulky v sql ?
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>	 <1077288899.2638.120.camel@localhost.localdomain>	 <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain>
Message-ID: <4039C9A6.9050507@pikebo.cz>

Michal Samek wrote:
>> Dan myslel  to, ze zaznam ktery  to GUI ukazuje ma  (musi mit:-) nejaky
>> jednoznacny identifkator  (PRIMARY KEY). Pred reloadem dat  toho GUI si
>> toto ID zapamatujete a pak v  novych datech opet naleznete a oznacite a
>> uzivateli ukazete.
> 
> 
> No prave, ted uz se opakuji, psal jsem, ze toto lze jedine v pripade, ze
> fetchnu cely rozsah zobrazovanych dat, a to zase nechci kvuli jejich
> rozsahu. Je to o par radku niz :) A navic, nac mam potom databazi, kdyz
> musim rucne neco hledat ve vysledku? 

Databazi tu mate od toho, aby obsahovala data a "odpovidala" na "dotazy" 
uzivatele nebo aplikace, ale rozhodne nevznikla jako podpora pro "psani 
GUI".

Z diskuse jsem vyrozumnel tomu, ze chcete napsat aplikaci, ktera 
umoznuje presne stejne nerozumny styl prace, jako aplikace stavajici. 
Pak si ovsem musite polozit otazku, zda bude mit tato aplikace vubec 
nejaky prinos pro uzivatele.

Byt ve Vasi pozici, nejspis bych se snazil uzivatele presvedcit o tom, 
ze nemaji hledana data vyhledavat ocima v nejakem seznamu, ale hlavou - 
chtit po pocitaci pouze tu podmnozinu dat, ktera se vejde na jednu 
obrazovku a pritom bude obsahovat hledana data.

Pokud se toto nepodari, pak nema smysl prechazet na technologii, kde se 
velmi tezko implementuje zvykove chovani predchozi aplikace.

Jan Serak



From zakkr na zf.jcu.cz  Mon Feb 23 11:09:39 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 23 Feb 2004 11:09:39 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077532493.1431.9.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain> <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz> <1077532493.1431.9.camel@localhost.localdomain>
Message-ID: <20040223100938.GD16876@zf.jcu.cz>

On Mon, Feb 23, 2004 at 11:34:54AM +0100, Michal Samek wrote:
> V Po, 23. 02. 2004 v 10.15, Karel Zak napsal:
> > On Mon, Feb 23, 2004 at 09:35:54AM +0100, Honza Pazdziora wrote:
> > > Vite, prijde mi, ze uz je to trosku nudne. Zjistil jste, ze se SQL
> > > chova jinak. Asi to budete muset akceptovat, chcete-li SQL pouzit.
> > 
> >  Presne. Vetsinu poslednich dopisu tohodle threadu jsem smazal s tim, ze
> >  dotycnemu neni pomoci. Pripada  mi jako nekdo kdo  dlouha leta pouzival
> >  na tahani nakladu  tank, a ted protoze ostatni uz  delsi dobu pouzivaji
> >  nakladak tak ho chce take. Jen ted zacal vsem okolo nadavat co je to za
> >  blbost ty blatniky vzdyt mu to brani na ten nakladak nasadit pasy...
> > 
> 
> Ja myslim, ze trosku prehanite. Zeptal jsem se na konkretni problem a

 Ja vim, ja rad (ale vetsinou s usmevem;-) 

> rozebrali jsme jej. To je vse. Dostali jsme se v podstate k tomu, ze je
> to bohuzel tak, jak to je a ze to s sql lepe udelat nepujde. To je to,

 Hodne jde o to jak jste  postupoval pri tom stanovovani si pozadavku na
 tu  aplikaci. IMHO asi  mozna i  nevedomky jste  to udelal  tak jak  se
 delaji nektera  ceska "vyberove  rizeni". Proste pozadavky,  ktere sedi
 jednomu dost  urcitemu reseni  a ostatni na  tom pohori. Lepsi  by bylo
 podivat se co mate za data a co ma byt vysledkem prace uzivatelu. A pak
 navrhnout reseni, ktere tydle dva body spoji.
 
 Dostal jste tu  rady, ktere v naproste vetsine vychazeji  z toho jak je
 delana  vetsina aplikaci  (tedy  select jen  potrebnuch veci,  zakladni
 sortovani ovlada GUI  widget, kursory). Ostatne mel jste  pravdu v tom,
 ze "todle nekdo musel uz resit". Ono prave browser je zaklad vetsiny DB
 aplikaci  --  nektere dokonce  ani  jiny  widget nepouzivaji  (takovata
 hrozna ucta co vypadaji jak sabat excelovskych tabulek...)
 
> co jsem chtel slyset, ve "vetsine poslednich dopisu" jsem vam do toho uz
> ani nepipnul. Prave proto, ze zcela jiste jsem "poznamenany" minulosti a
> vyvojem v xbase, jsem tady napsal, at mi poradi lide, co s sql maji
> radove vetsi zkusenosti. Nikomu jsem nenadaval a v podstate jste mi dali
> za pravdu, ze implementace takove situace pomoci sql *muze* byt mene
> efektivni nez v xbase. Nezbyva mi nez udelat prakticke testy a srovnat,
> zda to bude vubec vykonove pouzitelne, pripadne zmenit ui aplikace, coz
> ale bude problem - uzivatele mi to omlati o hlavu. 

 Ano. Take  zavadeni noveho  software neni  z  velke casti  ukol pro  IT
 oddeleni, ale pro  managment. Urcite je ale treba ty  usery sledovat --
 obcas totiz novy soft opravdu treba neni :-)

 Ostatne co  vlastne lepsiho ocekavate  od te aplikace pri  pouziti SQL?
 Todle je dost dulezita otazka.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From kluvanek na tesnet.cz  Mon Feb 23 11:14:08 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 11:14:08 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039C9A6.9050507@pikebo.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>	 <1077288899.2638.120.camel@localhost.localdomain>	 <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain> <4039C9A6.9050507@pikebo.cz>
Message-ID: <4039D270.2070309@trb.tesnet.cz>

Jan Serak napsal(a):
> Michal Samek wrote:
> 
>>> Dan myslel  to, ze zaznam ktery  to GUI ukazuje ma  (musi mit:-) nejaky
>>> jednoznacny identifkator  (PRIMARY KEY). Pred reloadem dat  toho GUI si
>>> toto ID zapamatujete a pak v  novych datech opet naleznete a oznacite a
>>> uzivateli ukazete.
>>
>>
>>
>> No prave, ted uz se opakuji, psal jsem, ze toto lze jedine v pripade, ze
>> fetchnu cely rozsah zobrazovanych dat, a to zase nechci kvuli jejich
>> rozsahu. Je to o par radku niz :) A navic, nac mam potom databazi, kdyz
>> musim rucne neco hledat ve vysledku? 
> 
> 
> Databazi tu mate od toho, aby obsahovala data a "odpovidala" na "dotazy" 
> uzivatele nebo aplikace, ale rozhodne nevznikla jako podpora pro "psani 
> GUI".
> 
> Z diskuse jsem vyrozumnel tomu, ze chcete napsat aplikaci, ktera 
> umoznuje presne stejne nerozumny styl prace, jako aplikace stavajici. 
> Pak si ovsem musite polozit otazku, zda bude mit tato aplikace vubec 
> nejaky prinos pro uzivatele.
> 
> Byt ve Vasi pozici, nejspis bych se snazil uzivatele presvedcit o tom, 
> ze nemaji hledana data vyhledavat ocima v nejakem seznamu, ale hlavou - 
> chtit po pocitaci pouze tu podmnozinu dat, ktera se vejde na jednu 
> obrazovku a pritom bude obsahovat hledana data.
Suhlas
Je treba zmenit pohlad na vec.
Trochu mi to pripomina mojich zamestnancov, ktori vsetko cpu do tabuliek v 
spreadsheet (exceli) i ked je to typicky priklad na DB (access). Oni su na to uz 
zvykli, tak tam cpu napriklad i zoznamy a divia sa , ze sa to neda nijak dalej 
spracovat. "Zdyt to tam napsat jde, tak co bych se ucil neco jineho. Proc bych 
to mel chtit tridit podle AUTORa?"
> 
> Pokud se toto nepodari, pak nema smysl prechazet na technologii, kde se 
> velmi tezko implementuje zvykove chovani predchozi aplikace.
> 
> Jan Serak
> 
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From kluvanek na tesnet.cz  Mon Feb 23 11:16:09 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 11:16:09 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223091935.GC16876@zf.jcu.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz> <4039C42C.6020303@trb.tesnet.cz> <20040223091935.GC16876@zf.jcu.cz>
Message-ID: <4039D2E9.7080103@trb.tesnet.cz>

Karel Zak napsal(a):

> On Mon, Feb 23, 2004 at 10:13:16AM +0100, Kluvanek Martin wrote:
> 
>>>	To je ovšem podružný a řešitelný probém - doplnit SQL serveru
>>>"hledané" vhodné indicie jako patřičné indexy - škálovat lze mnoha
>>>způsoby - od HW, přes návrh a normalizaci DB až po pomocné prostředky
>>>jako čištění (VACUUM v případě PgSQL) apod.
>>
>>No neviem, ako by vypadal index na tabulku kde sa filtruje podla 4 poli 
>>typu varchar a uzivatel si tam moze nacpat lubovolny nezmysel, k tomu este 
>>asi 9 numerickych poli.
> 
> 
>  CREATE INDEX idx ON tabname ( f1, f2, f3, f4 );
:-))
Jasne, lenze
1)tie indexy budu silene, pretoze budu kopirovat cele to povidani co tam 
uzivatel napisal.
2)nakoniec to stejne asi bude prehladavat sekvencne pretoze niesom si isty, ci 
polozka typu varchar2(4000) je rozumne indexovatelna.


 >	Prominte, ale vy jste v zivote nepouzil JINY index nez pres
jeden sloupec?

Samozrejme ze pouzil, ale len cez "rozumne" polia typu cas,vstup (date, number)
ale nie cez poznamka varchar2(4000) s hodnotami ako "kdyz jsem tam prisel, tak 
uz uztredna 9mu11a-1 byla down a data byla definitivne ztracena. Pak jsem...atd..."
filter hlada napr. poznamka  like '%9mu11%'



-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From adelton na informatics.muni.cz  Mon Feb 23 11:32:10 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Mon, 23 Feb 2004 11:32:10 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039D2E9.7080103@trb.tesnet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A57@percival.fonet.cz> <4039C42C.6020303@trb.tesnet.cz> <20040223091935.GC16876@zf.jcu.cz> <4039D2E9.7080103@trb.tesnet.cz>
Message-ID: <20040223103210.GC2538@anxur.fi.muni.cz>

On Mon, Feb 23, 2004 at 11:16:09AM +0100, Kluvanek Martin wrote:
> 
> Samozrejme ze pouzil, ale len cez "rozumne" polia typu cas,vstup (date, 
> number)
> ale nie cez poznamka varchar2(4000) s hodnotami ako "kdyz jsem tam prisel, 
> tak uz uztredna 9mu11a-1 byla down a data byla definitivne ztracena. Pak 
> jsem...atd..."
> filter hlada napr. poznamka  like '%9mu11%'

Na tohle ale zase existuji napriklad fulltextove ci polofulltextove
indexy. Cili zase uplne jine cviceni nez "browse pres vsechno".

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From Janousek na FoNet.Cz  Mon Feb 23 11:32:33 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Mon, 23 Feb 2004 11:32:33 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4039D2E9.7080103@trb.tesnet.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A5A@percival.fonet.cz>

> -----Original Message-----
> From: Kluvanek Martin [mailto:kluvanek na tesnet.cz] 
er)
> ale nie cez poznamka varchar2(4000) s hodnotami ako "kdyz 
> jsem tam prisel, tak 
> uz uztredna 9mu11a-1 byla down a data byla definitivne 
> ztracena. Pak jsem...atd..."
> filter hlada napr. poznamka  like '%9mu11%'

	Pak bych se zeptal - jak casto pouzivate takove dotazy? Casto -
na to je zrejme nejvhodnejsi fulltext, zridka - pak prece tu
neoptimalnost prezijete, neb jine reseni ma neopodstatnenou narocnost.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From spec_list na tony.cz  Mon Feb 23 12:23:44 2004
From: spec_list na tony.cz (Michal Samek)
Date: 23 Feb 2004 12:23:44 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223100938.GD16876@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
	 <1077288899.2638.120.camel@localhost.localdomain>
	 <20040220151546.GE3644@zf.jcu.cz>
	 <1077357227.3915.4.camel@localhost.localdomain>
	 <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz>
	 <1077532493.1431.9.camel@localhost.localdomain>
	 <20040223100938.GD16876@zf.jcu.cz>
Message-ID: <1077535422.1499.33.camel@localhost.localdomain>

V Po, 23. 02. 2004 v 11.09, Karel Zak napsal:
> On Mon, Feb 23, 2004 at 11:34:54AM +0100, Michal Samek wrote:
> > 
> > Ja myslim, ze trosku prehanite. Zeptal jsem se na konkretni problem a
> 
>  Ja vim, ja rad (ale vetsinou s usmevem;-) 
> 
> > rozebrali jsme jej. To je vse. Dostali jsme se v podstate k tomu, ze je
> > to bohuzel tak, jak to je a ze to s sql lepe udelat nepujde. To je to,
> 
>  Hodne jde o to jak jste  postupoval pri tom stanovovani si pozadavku na
>  tu  aplikaci. IMHO asi  mozna i  nevedomky jste  to udelal  tak jak  se
>  delaji nektera  ceska "vyberove  rizeni". Proste pozadavky,  ktere sedi
>  jednomu dost  urcitemu reseni  a ostatni na  tom pohori. Lepsi  by bylo
>  podivat se co mate za data a co ma byt vysledkem prace uzivatelu. A pak
>  navrhnout reseni, ktere tydle dva body spoji.
>  
>  Dostal jste tu  rady, ktere v naproste vetsine vychazeji  z toho jak je
>  delana  vetsina aplikaci  (tedy  select jen  potrebnuch veci,  zakladni
>  sortovani ovlada GUI  widget, kursory). Ostatne mel jste  pravdu v tom,
>  ze "todle nekdo musel uz resit". Ono prave browser je zaklad vetsiny DB
>  aplikaci  --  nektere dokonce  ani  jiny  widget nepouzivaji  (takovata
>  hrozna ucta co vypadaji jak sabat excelovskych tabulek...)
>  
> > co jsem chtel slyset, ve "vetsine poslednich dopisu" jsem vam do toho uz
> > ani nepipnul. Prave proto, ze zcela jiste jsem "poznamenany" minulosti a
> > vyvojem v xbase, jsem tady napsal, at mi poradi lide, co s sql maji
> > radove vetsi zkusenosti. Nikomu jsem nenadaval a v podstate jste mi dali
> > za pravdu, ze implementace takove situace pomoci sql *muze* byt mene
> > efektivni nez v xbase. Nezbyva mi nez udelat prakticke testy a srovnat,
> > zda to bude vubec vykonove pouzitelne, pripadne zmenit ui aplikace, coz
> > ale bude problem - uzivatele mi to omlati o hlavu. 
> 
>  Ano. Take  zavadeni noveho  software neni  z  velke casti  ukol pro  IT
>  oddeleni, ale pro  managment. Urcite je ale treba ty  usery sledovat --
>  obcas totiz novy soft opravdu treba neni :-)

Funkcne je ten stary software velmi kvalitni, je v tom 10 let vyvoje a
natlaku na dodavatele. Plus hromada utilit kolem toho, ktere
automatizuji spoustu operaci. Velmi dobre nam to dnes modeluje firemni
procesy. 

Problematicka zacina byt pouzita technologie a fakt, ze sw se uz dale
nevyviji a kody od toho nikdy nedostanem. Protoze dosemu se sambou neni
pouzitelne prostredi (problemy se zamykanim), musime tu mit na stanicich
winy a to jeste 98, v novejsich je dos taky emulovany a nejede to dobre.
Taky stabilita pri dnesnim rozsahu dat neni uplne dobra (ani spatna, ale
obcas to spadne a lepsi to uz nebude). Proste to moralne zastaralo.
Dneska staci, kdyz si nase draha vlada vymysli 3. sazbu dph a jsme v
p....

> 
>  Ostatne co  vlastne lepsiho ocekavate  od te aplikace pri  pouziti SQL?
>  Todle je dost dulezita otazka.

Ja mam jinak sql rad a postgres zvlaste, ono moc z ceho vybirat si taky
neni, existuji sice nejake obskurni projekty typu harbour, ale to bych
pro produkcni system neriskoval. Problem je v tom, ze jsem zatim delal v
sql spise pro web, kde to prirozene funguje stylem request-result, takze
jsem na tenhle problem jeste nenarazil. S gui a sql to zkousim poprve. A
trosku mne zarazila ta pracnost takove implementace.

> 
>     Karel
-- 
Michal Samek <spec_list na tony.cz>


From zakkr na zf.jcu.cz  Mon Feb 23 11:57:51 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Mon, 23 Feb 2004 11:57:51 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077535422.1499.33.camel@localhost.localdomain>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz> <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain> <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz> <1077532493.1431.9.camel@localhost.localdomain> <20040223100938.GD16876@zf.jcu.cz> <1077535422.1499.33.camel@localhost.localdomain>
Message-ID: <20040223105751.GE16876@zf.jcu.cz>

On Mon, Feb 23, 2004 at 12:23:44PM +0100, Michal Samek wrote:
> >  Ostatne co  vlastne lepsiho ocekavate  od te aplikace pri  pouziti SQL?
> >  Todle je dost dulezita otazka.
> 
> Ja mam jinak sql rad a postgres zvlaste, ono moc z ceho vybirat si taky
> neni, existuji sice nejake obskurni projekty typu harbour, ale to bych
> pro produkcni system neriskoval. Problem je v tom, ze jsem zatim delal v
> sql spise pro web, kde to prirozene funguje stylem request-result, takze

 Mozna i todle co chcete by slo udelat jako web aplikaci. I kdyz i
 tato technologie neni vzdy to prave.

> jsem na tenhle problem jeste nenarazil. S gui a sql to zkousim poprve. A
> trosku mne zarazila ta pracnost takove implementace.

 To je dan za naproste oddeleni datove vrstvy od zbytku aplikace.
 
    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From spec_list na tony.cz  Mon Feb 23 13:05:28 2004
From: spec_list na tony.cz (Michal Samek)
Date: 23 Feb 2004 13:05:28 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223105751.GE16876@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D040869@EXCH2.mmp.plzen-city.cz>
	 <1077288899.2638.120.camel@localhost.localdomain>
	 <20040220151546.GE3644@zf.jcu.cz>
	 <1077357227.3915.4.camel@localhost.localdomain>
	 <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz>
	 <1077532493.1431.9.camel@localhost.localdomain>
	 <20040223100938.GD16876@zf.jcu.cz>
	 <1077535422.1499.33.camel@localhost.localdomain>
	 <20040223105751.GE16876@zf.jcu.cz>
Message-ID: <1077537927.1431.46.camel@localhost.localdomain>

V Po, 23. 02. 2004 v 11.57, Karel Zak napsal:

>  Mozna i todle co chcete by slo udelat jako web aplikaci. I kdyz i
>  tato technologie neni vzdy to prave.

O tomhle jsem se trosku rozepsal v diskusi na rootu u clanku o
MyCompany. Stejne by mne dokopali k tomu, aby tam byly nejake kontroly
hodnot zadavanych fieldu a dalsi a dalsi interaktivita, takze bych se
ujavascriptoval :) To mi uz pripada jednodussi udelat si nejaky treba i
univerzalni klient, ktery se nakrmi objekty z nejake mezivrstvy a
postara se o rozhrani. A jsme u toho 3-vrstvoveho modelu... V tomto
pripade to uz zacina mit smysl, nejaka vrstva, ktera ma prehled o
pripojenych klientech a komunikuje za ne s sql serverem a hlida si, co
pachaji klienti.

> 
> > jsem na tenhle problem jeste nenarazil. S gui a sql to zkousim poprve. A
> > trosku mne zarazila ta pracnost takove implementace.
> 
>  To je dan za naproste oddeleni datove vrstvy od zbytku aplikace. 

To chapu, spis jsem si rikal, ze pokud teda je to tak, jak si myslim,
jak to, ze jsem jeste nenarazil na nejake widgety, ktere to trosku resi.
Asi to vsichni delaji tak, ze chteji po uzivateli nejdriv filtr, pak mu
ukazou nejaka data. Nebo to neresi a proste to nechaji non-scalable.
 
>  
>  
>     Karel
-- 
Michal Samek <spec_list na tony.cz>


From kluvanek na tesnet.cz  Mon Feb 23 12:14:10 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 12:14:10 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF4430178A5A@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A5A@percival.fonet.cz>
Message-ID: <4039E082.2080200@trb.tesnet.cz>

Ing. Pavel Janousek napsal(a):

>> -----Original Message----- From: Kluvanek Martin
>> [mailto:kluvanek na tesnet.cz]
> 
> er)
> 
>> ale nie cez poznamka varchar2(4000) s hodnotami ako "kdyz jsem tam prisel,
>> tak uz uztredna 9mu11a-1 byla down a data byla definitivne ztracena. Pak
>> jsem...atd..." filter hlada napr. poznamka  like '%9mu11%'
> 
....
> Na tohle ale zase existuji napriklad fulltextove ci polofulltextove indexy.
> Cili zase uplne jine cviceni nez "browse pres vsechno".
Jasne, ze to s browse pres vsechno az tak nesuvisi. tie fulltextove indexy som
len tusil.
....
> 
> Pak bych se zeptal - jak casto pouzivate takove dotazy? Casto - na to je
> zrejme nejvhodnejsi fulltext, zridka - pak prece tu neoptimalnost prezijete,
> neb jine reseni ma neopodstatnenou narocnost.
Vsak som sa k tomu tak i postavil.
V 100tisic zaznamoch to este nieje taka tragedia na to ze sa to pouzije obcas. 
zatial sa to da vydrzat.
Neviem, do akej miery si to ORACLE ulahcuje pri opakovani dotazu s tym, ze chcem 
len dalsiu stranku (po 20 zaznamoch), ale zatial to nejak nespomaluje pracu, tak 
to neriesim, ked to zacne vadit, tak to zacnem riesit.
Vychadzam z toho, ze ked to userovi vrati ako odpoved na filtrovaci dotaz viac 
ako 1000 zaznamov, tak je asi niekde chybka. Ked na tom user trva, tak mu kludne 
tu hromadu budem strankovat na 3000 stranok po 20, len je neprijemne ze neviem 
ci ked si zobrazujem riadky niekde z konca, tak ci to chudak musi prehladavat 
cele znova a od zaciatku (asi ano).

Skorej ma trochu irituje to ze sa to odkazuje na rownum a teoreticky niekto iny 
moze zmenit data a mne nebude sediet strankovanie (posunu sa hranice stranok 
pripadne sa zmeni celkovy pocet stranok/zaznamov v odpovedi). Ale pretoze sa to 
moze stat len pri beho jedneho robotka o 4:00 v noci, tak pouzivam aplikacny 
zamok (fuj) a ked by k rozstrankovaniu doslo, tak to stejne nesposobi ziadnu 
velku katastrofu, tak to tiez nijak extra neriesim.

Je to WEB aplikacia takze stejne nehrozi zurive listovanie v 100tis zaznamoch s 
drzanim PageDown...


> 
> ------------------------------------------------------------------- Ing.
> Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o. Technicka podpora,
> Intranet/Internet     Sokolova 67, 619 00 Brno E-mail:
> mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749 WWW:
> http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz 
> -------------------------------------------------------------------
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From tomas na neo.cz  Mon Feb 23 13:43:40 2004
From: tomas na neo.cz (Kouba Tomas)
Date: Mon, 23 Feb 2004 13:43:40 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <20040223091539.GB16876@zf.jcu.cz>
Message-ID: <NCBBJLACFPFKJGDJKDNFKEBLNIAA.tomas@neo.cz>

Zdravim a preji pekny den,

to je ale trochu neco jineho. Pokud se aplikace s Accessem (Jet) pise trochu
inteligentne, je velmi snadne ji preklopit pro praci s SQL serverem.

Ja pana Samka (puvodniho tazatele) trochu chapu. Ocekaval od dospelejsi
technologie pouze rozsireni funkcnosti a zadna omezeni proti stare
technologii a ono ejhle, neni to tak...

--
Kouba Tomas
mailto:tomas na neo.cz

>
>  Ostatne kouknete se treba na M$, delaji jak SQL tak i Acceess a jak
>  se zda tak si nekonkuruji a sve misto na trhu ma oboje.
>



From Janousek na FoNet.Cz  Mon Feb 23 13:47:36 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Mon, 23 Feb 2004 13:47:36 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <NCBBJLACFPFKJGDJKDNFKEBLNIAA.tomas@neo.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A5E@percival.fonet.cz>

> -----Original Message-----
> From: Kouba Tomas [mailto:tomas na neo.cz] 
> Ja pana Samka (puvodniho tazatele) trochu chapu. Ocekaval od 
> dospelejsi
> technologie pouze rozsireni funkcnosti a zadna omezeni proti stare
> technologii a ono ejhle, neni to tak...

:-) možná byste si měl něco o historii SQL a jak to bylo (že to
vymyslelo IBM, pak to zahodilo jako neupotřebitelné (asi jako více jak 5
počítačů:->) a pak zpětně kupovalo od dnešního Oracle) přečíst. Ano,
přímé oddělení dat od aplikace je asi o 10 let vývojově starší, tím ale
faktogtrafická rozdílnost končí (pomiňmě prosím, že ve zdejších
končinách ješte na začátku 90.-tých let dominovala FoxPro, PC Fand a
ještě delší a hlubší bylo nadšení z MS Accessu).

PS: Jako dobrý materiál pro začátek může sloužit něco z historie
dnešního Oracle nebo přímo o jeho největším akcionáři, když už ne o SQL
jako takovém.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From DZIPOLDKBP na contactme.bz  Mon Feb 23 13:49:36 2004
From: DZIPOLDKBP na contactme.bz (Saul Maher)
Date: Mon, 23 Feb 2004 13:49:36 +0100
Subject: Your friend said this hay
Message-ID: <MSDXVLDGYLBYGZXSABLQ@modomail.com>

24022369645059211

G.E.N.ERIC Cialis get hard upto 36 hours
http://rd.yahoo.com/dir/?http://www.er4xds.com/cu/


dentistry hansom sock ocean honk evasion method bean appraisal intransitiv=
e benign crandall portal yeasty accreditation discrete agriculture modest =
anyhow decedent injunction carp boardinghouse position=20 greenbelt barrow=
 conferrable extendible divisible atalanta parley vietnamese vacuo oatmeal=
 timid practise strafe actor adject thyme=20
24022369645059211



From kluvanek na tesnet.cz  Mon Feb 23 13:54:45 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 13:54:45 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <4F23E9745D562F4D90373B9C5CEF4430178A5E@percival.fonet.cz>
References: <4F23E9745D562F4D90373B9C5CEF4430178A5E@percival.fonet.cz>
Message-ID: <4039F815.9070806@trb.tesnet.cz>

Ing. Pavel Janousek napsal(a):

>>-----Original Message-----
>>From: Kouba Tomas [mailto:tomas na neo.cz] 
>>Ja pana Samka (puvodniho tazatele) trochu chapu. Ocekaval od 
>>dospelejsi
>>technologie pouze rozsireni funkcnosti a zadna omezeni proti stare
>>technologii a ono ejhle, neni to tak...
> 
> 
> :-) možná byste si měl něco o historii SQL a jak to bylo (že to
> vymyslelo IBM, pak to zahodilo jako neupotřebitelné (asi jako více jak 5
> počítačů:->) a pak zpětně kupovalo od dnešního Oracle) přečíst. Ano,
> přímé oddělení dat od aplikace je asi o 10 let vývojově starší, tím ale
> faktogtrafická rozdílnost končí (pomiňmě prosím, že ve zdejších
> končinách ješte na začátku 90.-tých let dominovala FoxPro, PC Fand a
> ještě delší a hlubší bylo nadšení z MS Accessu).
No to bolo fantasticke. :-)
Viem, ze jeden znamy na slovensku bol z toho cely PAF, ze vyberove riadenie na 
financnicky system pre tusim ze Komercnu Banku ci koho vyhralo nejake riesenie 
na FoxPro...
> 
> PS: Jako dobrý materiál pro začátek může sloužit něco z historie
> dnešního Oracle nebo přímo o jeho největším akcionáři, když už ne o SQL
> jako takovém.

Jo pekne som sa pobavil, nedawno v nejakom platku som to cital.
Tie svine z narodnej obrany mu nedovolili zakupit MIG....
:))

> 
> -------------------------------------------------------------------
> Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
> Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
> E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
> WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
> -------------------------------------------------------------------
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From sherry na pikebo.cz  Mon Feb 23 13:59:21 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Mon, 23 Feb 2004 13:59:21 +0100
Subject: Folklor okolo puvodniho dotazu (Re: Jak na browse velke tabulky v
 sql ?)
References: <NCBBJLACFPFKJGDJKDNFKEBLNIAA.tomas@neo.cz>
Message-ID: <4039F929.8070501@pikebo.cz>

Kouba Tomas wrote:
> Ja pana Samka (puvodniho tazatele) trochu chapu. Ocekaval od dospelejsi
> technologie pouze rozsireni funkcnosti a zadna omezeni proti stare
> technologii a ono ejhle, neni to tak...

A neni sam. Prvni takto zmatene lidi jsem potkal nekdy na prelomu let 
1993 a 1994. Vyjadrovali se v tom smyslu, ze Oracle je pekna s***ka, 
kdyz ani nema ukazatel na aktualni zaznam ;-) nebot ten "jejich" Magic 
to ma a proto je lepsi.

Btw. slyseli jste nekdo nekdy o RDBMS Magic? ;-)
A to je jakysi software napsany pro tento RDBMS nositelem zlate medaile 
Mezinarodniho strojirenskeho veletrhu nekdy z prelomu 80. a 90. let!

Nejvetsi problem programatoru (a tim nemyslim nikoho konkretniho) je 
zbavit se zabehnuteho zpusobu uvazovani a "otevrit mysl". Neni to vubec 
jednoduche. Pro sebe mam zatim vyzkousenu jedinou fungujici metodu 
spocivajici v konzumaci neumerne velkeho mnozstvi alkoholu, coz se 
bohuzel neda pouzivat moc casto ;-)

Proste programator presunujici se z Pascalu do C se musi obejit bez 
"funkci definovanych uvnitr funkce", programator pracujici v C musi 
stravit, kdyz mu v Jave zmizi pointry, foxista musi zmenit uvazovani, 
kdyz se chce vrhnout do relacniho kalkulu atd. atd. Pokud by totiz 
dospelejsi technologie pouze rozsirovaly nejaky starsi koncept, tak 
bychom v SQL meli prikaz k nastaveni hodnoty registru procesoru.

Jan Serak



From kluvanek na tesnet.cz  Mon Feb 23 14:21:57 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Mon, 23 Feb 2004 14:21:57 +0100
Subject: Folklor okolo puvodniho dotazu (Re: Jak na browse velke tabulky
 v sql ?)
In-Reply-To: <4039F929.8070501@pikebo.cz>
References: <NCBBJLACFPFKJGDJKDNFKEBLNIAA.tomas@neo.cz> <4039F929.8070501@pikebo.cz>
Message-ID: <4039FE75.5010900@trb.tesnet.cz>

Jan Serak napsal(a):

> Kouba Tomas wrote:
> 
>> Ja pana Samka (puvodniho tazatele) trochu chapu. Ocekaval od dospelejsi
>> technologie pouze rozsireni funkcnosti a zadna omezeni proti stare
>> technologii a ono ejhle, neni to tak...
> 
> 
> A neni sam. Prvni takto zmatene lidi jsem potkal nekdy na prelomu let 
> 1993 a 1994. Vyjadrovali se v tom smyslu, ze Oracle je pekna s***ka, 
> kdyz ani nema ukazatel na aktualni zaznam ;-) nebot ten "jejich" Magic 
> to ma a proto je lepsi.
> 
> Btw. slyseli jste nekdo nekdy o RDBMS Magic? ;-)
> A to je jakysi software napsany pro tento RDBMS nositelem zlate medaile 
> Mezinarodniho strojirenskeho veletrhu nekdy z prelomu 80. a 90. let!
>
Jo slysel. JEden znamy o tom basnil... :-)


> Nejvetsi problem programatoru (a tim nemyslim nikoho konkretniho) je 
> zbavit se zabehnuteho zpusobu uvazovani a "otevrit mysl". Neni to vubec 
> jednoduche. Pro sebe mam zatim vyzkousenu jedinou fungujici metodu 
> spocivajici v konzumaci neumerne velkeho mnozstvi alkoholu, coz se 
> bohuzel neda pouzivat moc casto ;-)
AEPROM
Lihem mazatelna pamet.

Proste treba spravit ten cimrmanovsky ukrok stranou (a k tomu este 4x dozadu)
Vseobecne mam pocit ze sa v mojich kruhoch malo projektuje a rovno hrr na ne...
A ked je to hotove, tak sa premysla nad tym, ako by to malo fungovat a co by sa 
od toho malo chciet.

> 
> Proste programator presunujici se z Pascalu do C se musi obejit bez 
> "funkci definovanych uvnitr funkce", programator pracujici v C musi 
> stravit, kdyz mu v Jave zmizi pointry, foxista musi zmenit uvazovani, 
> kdyz se chce vrhnout do relacniho kalkulu atd. atd. Pokud by totiz 
> dospelejsi technologie pouze rozsirovaly nejaky starsi koncept, tak 
> bychom v SQL meli prikaz k nastaveni hodnoty registru procesoru.
A to by sa cvakalo na packovych prepinacoch po jednotlivych bitoch....
Apropos.
Spomina si niektory z panov na rucne cvakanie boot loaderov prepinacmi ?
Ach jo.....To tomu clovek este rozumel....
16 kslov operacnej (feritovej) pamate
ultrazvukove pamate, magn.bubnove pamate.
2MB disky IZOT, pomackana hromada dernych stitkov s jedinou kopiou programu...
A bolo tak tak pekne prehladne.
:)


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From mike na mk-sys.cz  Mon Feb 23 19:24:08 2004
From: mike na mk-sys.cz (Michal Kubecek)
Date: Mon, 23 Feb 2004 19:24:08 +0100
Subject: Jak na browse velke tabulky v sql ?
In-Reply-To: <1077537927.1431.46.camel@localhost.localdomain>
References: <1077288899.2638.120.camel@localhost.localdomain> <20040220151546.GE3644@zf.jcu.cz> <1077357227.3915.4.camel@localhost.localdomain> <20040223083554.GA2538@anxur.fi.muni.cz> <20040223091539.GB16876@zf.jcu.cz> <1077532493.1431.9.camel@localhost.localdomain> <20040223100938.GD16876@zf.jcu.cz> <1077535422.1499.33.camel@localhost.localdomain> <20040223105751.GE16876@zf.jcu.cz> <1077537927.1431.46.camel@localhost.localdomain>
Message-ID: <20040223182408.GA5974@kubecekserver.mk-sys.cz>

On Mon, Feb 23, 2004 at 01:05:28PM +0100, Michal Samek wrote:
> V Po, 23. 02. 2004 v 11.57, Karel Zak napsal:
> 
> To chapu, spis jsem si rikal, ze pokud teda je to tak, jak si myslim,
> jak to, ze jsem jeste nenarazil na nejake widgety, ktere to trosku resi.

Ale ony samozřejmě existují, takové komponenty máte třeba v C++ Builderu,
ale jsou k dispozici i od třetích stran.

                                                         Michal Kubeček

From mkundrat na penguin.cz  Mon Feb 23 22:45:47 2004
From: mkundrat na penguin.cz (Milan KUNDRAT)
Date: Mon, 23 Feb 2004 22:45:47 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky?
Message-ID: <200402232245.47553.mkundrat@penguin.cz>


dobry den


pouzivam postgresql verzie 7.4.1.

mam vytvorenu tabulku
CREATE TABLE skupina
(
  id SERIAL,
  nazov CHAR (32) NOT NULL
);

a chcel by som na nu nahodit trigger
CREATE TRIGGER skupinaNovy
  BEFORE INSERT
  ON skupina
  FOR EACH ROW
  EXECUTE PROCEDURE skupinaNovyF ();

ktory by po pridani zaznamu v tabulke skupina vytvoril databazovu skupinu
CREATE OR REPLACE FUNCTION skupinaNovyF () RETURNS TRIGGER AS '
    BEGIN
      CREATE GROUP NEW.nazov;
      RETURN NEW;
    END;
  ' LANGUAGE 'plpgsql';

toto mi samozrejme nefunguje, lebo NEW.nazov je retazec znakov a do CREATE 
GROUP xyz sa nedava retazec.

neviete, prosim vas, ci a ako by sa to dalo spravit?

-- 
Milan KUNDRÁT

Email: mkundrat na penguin.cz
Icq: 172420788
Tel: +421/904/496 438


From stehule na kix.fsv.cvut.cz  Tue Feb 24 07:34:37 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Tue, 24 Feb 2004 07:34:37 +0100 (CET)
Subject: ako synchronizovat databazove skupiny podla tabulky?
In-Reply-To: <200402232245.47553.mkundrat@penguin.cz>
Message-ID: <Pine.LNX.4.44.0402240733130.9940-100000@kix.fsv.cvut.cz>

Zdravim

Mozna by pomohlo execute

http://developer.postgresql.org/docs/postgres/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN

Pavel Stehule

On Mon, 23 Feb 2004, Milan KUNDRAT wrote:

> 
> dobry den
> 
> 
> pouzivam postgresql verzie 7.4.1.
> 
> mam vytvorenu tabulku
> CREATE TABLE skupina
> (
>   id SERIAL,
>   nazov CHAR (32) NOT NULL
> );
> 
> a chcel by som na nu nahodit trigger
> CREATE TRIGGER skupinaNovy
>   BEFORE INSERT
>   ON skupina
>   FOR EACH ROW
>   EXECUTE PROCEDURE skupinaNovyF ();
> 
> ktory by po pridani zaznamu v tabulke skupina vytvoril databazovu skupinu
> CREATE OR REPLACE FUNCTION skupinaNovyF () RETURNS TRIGGER AS '
>     BEGIN
>       CREATE GROUP NEW.nazov;
>       RETURN NEW;
>     END;
>   ' LANGUAGE 'plpgsql';
> 
> toto mi samozrejme nefunguje, lebo NEW.nazov je retazec znakov a do CREATE 
> GROUP xyz sa nedava retazec.
> 
> neviete, prosim vas, ci a ako by sa to dalo spravit?
> 
> 


From sherry na pikebo.cz  Tue Feb 24 07:29:25 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Tue, 24 Feb 2004 07:29:25 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky?
References: <200402232245.47553.mkundrat@penguin.cz>
Message-ID: <403AEF45.3060103@pikebo.cz>

Milan KUNDRAT wrote:
> dobry den
> 
> 
> pouzivam postgresql verzie 7.4.1.

Postgresql neznam, odpoved bude obecna.

[...]

> ktory by po pridani zaznamu v tabulke skupina vytvoril databazovu skupinu
> CREATE OR REPLACE FUNCTION skupinaNovyF () RETURNS TRIGGER AS '
>     BEGIN
>       CREATE GROUP NEW.nazov;
>       RETURN NEW;
>     END;
>   ' LANGUAGE 'plpgsql';
> 
> toto mi samozrejme nefunguje, lebo NEW.nazov je retazec znakov a do CREATE 
> GROUP xyz sa nedava retazec.

Podle meho nazoru to nebude fungovat nikdy. Snazite se totiz uvnitr DML 
(Data Manipulation Language) pouzit prikaz DDL (Data Definition 
Language), i kdyz se muze zdat, ze skupina nedefinuje datovou strukturu.

Prikazy DDL jsou VZDY samostatnymi transakcemi. Jak by se mel Postgresql 
(ale i cokoli jineho) podle Vas zachovat, kdybyste hypoteticky dosahl 
sveho zameru a pak mu predlozil:

	INSERT INTO vase_tabulka ... (pritom trigger zalozi skupinu)
	ROLLBACK;

Jan Serak




From adelton na informatics.muni.cz  Tue Feb 24 09:37:42 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Tue, 24 Feb 2004 09:37:42 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky?
In-Reply-To: <403AEF45.3060103@pikebo.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz>
Message-ID: <20040224083742.GA29071@anxur.fi.muni.cz>

On Tue, Feb 24, 2004 at 07:29:25AM +0100, Jan Serak wrote:
> >
> >pouzivam postgresql verzie 7.4.1.
> 
> Postgresql neznam, odpoved bude obecna.

Praveze ne. To, ze Oracle po DDL operaci dela commit neznamena, ze
to je obecny princip.

> >ktory by po pridani zaznamu v tabulke skupina vytvoril databazovu skupinu
> >CREATE OR REPLACE FUNCTION skupinaNovyF () RETURNS TRIGGER AS '
> >    BEGIN
> >      CREATE GROUP NEW.nazov;
> >      RETURN NEW;
> >    END;
> >  ' LANGUAGE 'plpgsql';
> >
> >toto mi samozrejme nefunguje, lebo NEW.nazov je retazec znakov a do CREATE 
> >GROUP xyz sa nedava retazec.

Je treba ten prikaz vytvorit a spustit pomoci

	execute 'create group ' || new.nazov;

> Podle meho nazoru to nebude fungovat nikdy. Snazite se totiz uvnitr DML 
> (Data Manipulation Language) pouzit prikaz DDL (Data Definition 
> Language), i kdyz se muze zdat, ze skupina nedefinuje datovou strukturu.
> 
> Prikazy DDL jsou VZDY samostatnymi transakcemi. Jak by se mel Postgresql 
> (ale i cokoli jineho) podle Vas zachovat, kdybyste hypoteticky dosahl 
> sveho zameru a pak mu predlozil:
> 
> 	INSERT INTO vase_tabulka ... (pritom trigger zalozi skupinu)
> 	ROLLBACK;

> select * from skupina ;
id,nazov
[0 rows of 2 fields returned]
> select * from jezek1 ;
DBD::Pg::st execute failed: ERROR:  Relation "jezek1" does not exist.
> /rollback
> select * from jezek2 ;
DBD::Pg::st execute failed: ERROR:  Relation "jezek2" does not exist.
> /rollback
> insert into skupina values (1, 'jezek1') ;
[1 row affected]
> select * from jezek1 ;
id
[0 rows of 1 fields returned]
> insert into skupina values (1, 'jezek2') ;
[1 row affected]
> select * from jezek2 ;
id
[0 rows of 1 fields returned]
> select * from skupina ;
id,nazov
'1','jezek1                          '
'1','jezek2                          '
[2 rows of 2 fields returned]
> /rollback
> select * from jezek2 ;
DBD::Pg::st execute failed: ERROR:  Relation "jezek2" does not exist.

Tedy je videt, ze Postgres ma DDL operace ve standardnim transakcnim
modu.

> select * from skupina ;
id,nazov
[0 rows of 2 fields returned]
> drop table skupina ;
[unknown number of rows affected]
> select * from skupina ;
DBD::Pg::st execute failed: ERROR:  Relation "skupina" does not exist.
> /rollback
> select * from skupina ;
id,nazov
[0 rows of 2 fields returned]

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From zakkr na zf.jcu.cz  Tue Feb 24 10:23:56 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Tue, 24 Feb 2004 10:23:56 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky?
In-Reply-To: <200402232245.47553.mkundrat@penguin.cz>
References: <200402232245.47553.mkundrat@penguin.cz>
Message-ID: <20040224092356.GA16623@zf.jcu.cz>

On Mon, Feb 23, 2004 at 10:45:47PM +0100, Milan KUNDRAT wrote:
> ktory by po pridani zaznamu v tabulke skupina vytvoril databazovu skupinu

 Jinak pro _experimentatory_ CREATE GROUP neni vnitrne nic jineho nez
 insert do pg_group:

 # INSERT INTO pg_group VALUES ('badboys', 1);
 # ALTER GROUP badboys ADD USER zakkr;

 # SELECT * FROM pg_group;
  groname | grosysid | grolist 
  ---------+----------+---------
   badboys |        1 | {100}
   

 proto  CREATE GROUP/USER  chodi transakcne. Pri  commitu transakce  pak
 jeste  udela update  souboru base/pg_group  a posle  signal postmastru,
 ktery tendle textovy soubor pouziva.

 Take je otazkou ma-li smysl pouzivat svuj vlastni tabulku se skupinama,
 kdyz v katalogu je to same a muzete usetrit jeden trigger a tu tabulku.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From mkundrat na penguin.cz  Tue Feb 24 12:09:20 2004
From: mkundrat na penguin.cz (Milan KUNDRAT)
Date: Tue, 24 Feb 2004 12:09:20 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky?
In-Reply-To: <20040224092356.GA16623@zf.jcu.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <20040224092356.GA16623@zf.jcu.cz>
Message-ID: <200402241209.23084.mkundrat@penguin.cz>

On Ut 24. Február 2004 10:23, si napísal:
>  Take je otazkou ma-li smysl pouzivat svuj vlastni tabulku se skupinama,
>  kdyz v katalogu je to same a muzete usetrit jeden trigger a tu tabulku.
dovod je ten, ze robim informacny system. pristup k nemu je cez web a http 
autentizacia (pouzivam .htaccess) sa robi oproti postgresql, kde uzivatelske 
mena a hesla su ulozene v tabulkach. no a ja tych uzivatelov zatriedim do 
skupin a podla tych skupin chcem nastavit pristupove prava k tabulkam. mozno 
sa to dalo vyriesit ja inak ale mna napadol prave takyto sposob :-)

-- 
Milan KUNDRÁT

Email: mkundrat na penguin.cz
Icq: 172420788
Tel: +421/904/496 438


From mkundrat na penguin.cz  Tue Feb 24 14:35:43 2004
From: mkundrat na penguin.cz (Milan KUNDRAT)
Date: Tue, 24 Feb 2004 14:35:43 +0100
Subject: ako synchronizovat databazove skupiny podla tabulky? - vyriesene
In-Reply-To: <20040224083742.GA29071@anxur.fi.muni.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz>
Message-ID: <200402241435.43742.mkundrat@penguin.cz>


toto spravilo presne to co som chcel :-)
execute 'create group ' || new.nazov;

dakujem

-- 
Milan KUNDRÁT

Email: mkundrat na penguin.cz
Icq: 172420788
Tel: +421/904/496 438


From sherry na pikebo.cz  Wed Feb 25 09:56:25 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Wed, 25 Feb 2004 09:56:25 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny
 podla tabulky?)
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz>
Message-ID: <403C6339.3090704@pikebo.cz>

Honza Pazdziora wrote:
> On Tue, Feb 24, 2004 at 07:29:25AM +0100, Jan Serak wrote:
> 
>>>pouzivam postgresql verzie 7.4.1.
>>
>>Postgresql neznam, odpoved bude obecna.
> 
> 
> Praveze ne. To, ze Oracle po DDL operaci dela commit neznamena, ze
> to je obecny princip.

Vypada to, ze jsem v praxi perfektne ukazal, jak vypadaji myslenkova 
klise, o nichz jsem tu psal nedavno (browse velke tabulky). Moc se za to 
omlouvam vsem, ktere jsem svym prispevkem zmatl.

Kdyz nad tim ted uvazuju, tak zkousim najit duvod nebo priklad situace, 
kdy nelze po uspesnem provedeni DDL prikazu zmeny odvolat. Bez uspechu.
Teoreticky tomu tedy vubec nic nevadi.

Proc ale Oracle implementoval DDL tak, ze kazdy prikaz je samostatna 
transakce? Kdyz pominu jako duvod ojebavku, vzletne oznacovanou jako 
"limitation", tak jediny duvod je pruchodnost databaze (pripadne zmeny v 
datech se nemusi delat pres rollback segment).

Kazdopadne tohle byla posledni kapka, ktera me donuti ten zazracny 
PostreSQL nainstalovat ;-)

Jan Serak



From zakkr na zf.jcu.cz  Wed Feb 25 10:26:07 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Wed, 25 Feb 2004 10:26:07 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny podla tabulky?)
In-Reply-To: <403C6339.3090704@pikebo.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz>
Message-ID: <20040225092607.GD29814@zf.jcu.cz>

On Wed, Feb 25, 2004 at 09:56:25AM +0100, Jan Serak wrote:
> Honza Pazdziora wrote:
> >On Tue, Feb 24, 2004 at 07:29:25AM +0100, Jan Serak wrote:
> >
> >>>pouzivam postgresql verzie 7.4.1.
> >>
> >>Postgresql neznam, odpoved bude obecna.
> >
> >
> >Praveze ne. To, ze Oracle po DDL operaci dela commit neznamena, ze
> >to je obecny princip.
> 
> Vypada to, ze jsem v praxi perfektne ukazal, jak vypadaji myslenkova 
> klise, o nichz jsem tu psal nedavno (browse velke tabulky). Moc se za to 
> omlouvam vsem, ktere jsem svym prispevkem zmatl.
> 
> Kdyz nad tim ted uvazuju, tak zkousim najit duvod nebo priklad situace, 
> kdy nelze po uspesnem provedeni DDL prikazu zmeny odvolat. Bez uspechu.
> Teoreticky tomu tedy vubec nic nevadi.
> 
> Proc ale Oracle implementoval DDL tak, ze kazdy prikaz je samostatna 
> transakce? Kdyz pominu jako duvod ojebavku, vzletne oznacovanou jako 
> "limitation", tak jediny duvod je pruchodnost databaze (pripadne zmeny v 
> datech se nemusi delat pres rollback segment).

 Ty  "limitation"  a  pruchodnost  mohou  byt  dost  zasadni  duvod. Lze
 predpokladat,  ze zmeny  schematu, prav  apod. nejsou  zase tak  caste,
 ze  se proste  v  danem  pripade zvolilo  reseni,  ktere je  limitujici
 v  nekolika  malo  pripadech,  ale   v  beznem  nazazeni  toho  serveru
 efektivnejsi.  Ostatne pokud se clovek podiva na moznosti prav v Oracle
 a zapremysli jak  to implementovat bez nejakych vetsich  omezeni tak to
 neni vubec  snadne. Ostatne treba  do prav na  sloupce se  v PostgreSQL
 stale nikomu moc nechce.

 Nevim jak nyni, ale treba u MySQL bylo preba pri nekterych zmenach prav
 reloadovat nastaveni serveru.

> Kazdopadne tohle byla posledni kapka, ktera me donuti ten zazracny 
> PostreSQL nainstalovat ;-)

 Pochopitelne  ne   vse  je  plne  transakcni. CREATE   GROUP  je  velmi
 jednoducha  zalezitost implementovana  na  nekolika malo  radkach a  ta
 transakcnost se proste nabizela. Napriklad verze 6.5 jeste zadny CREATE
 GROUP nemala a delalo se to INSERTem.

 Jinak PostgreSQL urcite nainstalujte :-)

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From sherry na pikebo.cz  Wed Feb 25 10:40:05 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Wed, 25 Feb 2004 10:40:05 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove
 skupiny podla tabulky?)
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225092607.GD29814@zf.jcu.cz>
Message-ID: <403C6D75.8050100@pikebo.cz>

Karel Zak wrote:
>  Ty  "limitation"  a  pruchodnost  mohou  byt  dost  zasadni  duvod. Lze
>  predpokladat,  ze zmeny  schematu, prav  apod. nejsou  zase tak  caste,
>  ze  se proste  v  danem  pripade zvolilo  reseni,  ktere je  limitujici
>  v  nekolika  malo  pripadech,  ale   v  beznem  nazazeni  toho  serveru
>  efektivnejsi.

To je samozrejme a je to vec konkretniho omezeni a osobniho nazoru. 
Napr. jsem presvedcen, ze je bohapustou ojebavkou, kdyz je v tabulce 
sloupec X definovan jako VARCHAR2(200), pricemz:

SELECT max(length(x)) from tabulka;

vraci 20, a neni mozne udelat

ALTER TABLE tabulka MODIFY (x VARCHAR2(100));

Proste je to implementovane tak, ze tabulka, v niz se ma snizovat rozsah 
datoveho typu, musi byt prazdna a hotovo. Tecka.

>  Ostatne pokud se clovek podiva na moznosti prav v Oracle
>  a zapremysli jak  to implementovat bez nejakych vetsich  omezeni tak to
>  neni vubec  snadne. Ostatne treba  do prav na  sloupce se  v PostgreSQL
>  stale nikomu moc nechce.

To se vubec nedivim. Oracle ma novy produkt Oracle Label Security, ktery 
udajne resi pristupova prava k RADKUM tabulky - to se mi zatim nechce 
ani chapat uzivatelsky, natoz implementacne ;-)

Jan Serak



From jan.korinek na hp.com  Wed Feb 25 10:55:02 2004
From: jan.korinek na hp.com (Korinek, Jan)
Date: Wed, 25 Feb 2004 10:55:02 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny podla tabulky?)
Message-ID: <D0612A93240BC641ABC6FC6FCFC090AB035F1F7B@chkexc01.emea.cpqcorp.net>

> -----Original Message-----
> From: Karel Zak [mailto:zakkr na zf.jcu.cz] 
> Sent: Wednesday, February 25, 2004 10:26 AM
> To: databases na linux.cz
> Subject: Re: Transakcnost DDL & Oracle (Re: ako 
> synchronizovat databazove skupiny podla tabulky?)

>  Nevim jak nyni, ale treba u MySQL bylo preba pri nekterych 
> zmenach prav  reloadovat nastaveni serveru.

Nejde až tak úplně o reload serveru, ale jen práv, nicméně se to dělá stále. Samozřejmě pouze v případě přímých insertů do tabulek práv. V případě grantů a podobně dochází k aktualizaci paměťového obrazu práv automaticky.

Honza

From Janousek na FoNet.Cz  Wed Feb 25 11:10:45 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Wed, 25 Feb 2004 11:10:45 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny podla tabulky?)
In-Reply-To: <D0612A93240BC641ABC6FC6FCFC090AB035F1F7B@chkexc01.emea.cpqcorp.net>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A84@percival.fonet.cz>

> -----Original Message-----
> From: Korinek, Jan [mailto:jan.korinek na hp.com] 
> Nejde až tak úplně o reload serveru, ale jen práv, nicméně se 
> to dělá stále. Samozřejmě pouze v případě přímých insertů do 
> tabulek práv. V případě grantů a podobně dochází k 
> aktualizaci paměťového obrazu práv automaticky.

	Pokud jsem nezaspal dobu, pak se nejedná jen o práva, ale i o
přidání uživatele, přidání práva na databázi/tabulku pro konkrétního
uživatele apod... (sám jsem nucen to nastavovat a silně mě to krká). 

	Aby se celý datastor musel reinicializovat i při GRANT a REVOKE,
to bych už skutečně vytekl.

	Ani PostgreSQL není bez mouch, ale přidávání uživatelů, databází
atd. zvládá za běhu (zase nemá takové detailní nastavování jak bych
někdy rád, ale i zde už v nové (nebo přednejnovější) dohnal možnosti
MySQL, takže nyní je to 1:0 pro PostgreSQL v tomto zápase).

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From adelton na informatics.muni.cz  Wed Feb 25 11:31:53 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Wed, 25 Feb 2004 11:31:53 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny podla tabulky?)
In-Reply-To: <403C6339.3090704@pikebo.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz>
Message-ID: <20040225103153.GC25426@anxur.fi.muni.cz>

On Wed, Feb 25, 2004 at 09:56:25AM +0100, Jan Serak wrote:
> 
> Proc ale Oracle implementoval DDL tak, ze kazdy prikaz je samostatna 
> transakce? Kdyz pominu jako duvod ojebavku, vzletne oznacovanou jako 
> "limitation", tak jediny duvod je pruchodnost databaze (pripadne zmeny v 
> datech se nemusi delat pres rollback segment).

Ty duvody tam muzou byt. Napriklad muzes mit objekty, ktere holt
v rollback segmentech nejsou. Zkompilovana tela funkci a packagu
a naloadovane dynamicke knihovny. Proste DDL se muze tykat ruznych
veci. Navic pak mas problem s tim, ze se musis transakcne zacit chovat
i k optimizeru, protoze ten samy select, zopakovany po provedeni
nejake DDL operace, uz potrebuje jiny plan.

On taky ten PostgreSQL par verzi zpet (presne tu hlasku ted nemuzu
najit) kdyz clovek udelal drop table, tak napsal neco jako "ano, delam
to v transakci, ale ted rychle koukej udelat commit, protoze na drop
table neumim rollback".

> Kazdopadne tohle byla posledni kapka, ktera me donuti ten zazracny 
> PostreSQL nainstalovat ;-)

No, nemoznost radit podle ruznych jazykovych kriterii a nutnost rict
razeni pri vytvareni clusteru databaze (dokonce to ani neni per
databaze) je dosti otravna. Stejne jako neexistence packagu, a fakt,
ze temporary tabulka nema per session obsah, ale taky pouze existuje
per session. Abys nebyl zklamany.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From zakkr na zf.jcu.cz  Wed Feb 25 15:16:25 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Wed, 25 Feb 2004 15:16:25 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove skupiny podla tabulky?)
In-Reply-To: <20040225103153.GC25426@anxur.fi.muni.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz>
Message-ID: <20040225141625.GE29814@zf.jcu.cz>

On Wed, Feb 25, 2004 at 11:31:53AM +0100, Honza Pazdziora wrote:
> ze temporary tabulka nema per session obsah, ale taky pouze existuje
> per session. Abys nebyl zklamany.

 Tomu nerozumim. Obsah tabulky neni per session, ale tabulka samotna 
 per session je? 

 Ostatne stejne zklaman by mohl byt clovek pri prechodu na DB2, Informix
 nebo na pri prechodu z xbase ;-)  Pro mne je u Oracle zklamanim, ze pri
 debatach v konferenci nemuzu podivat do zdrojaku jek je tam co udelano.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Wed Feb 25 15:38:53 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Wed, 25 Feb 2004 15:38:53 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040225141625.GE29814@zf.jcu.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz>
Message-ID: <20040225143853.GI25426@anxur.fi.muni.cz>

On Wed, Feb 25, 2004 at 03:16:25PM +0100, Karel Zak wrote:
> On Wed, Feb 25, 2004 at 11:31:53AM +0100, Honza Pazdziora wrote:
> > ze temporary tabulka nema per session obsah, ale taky pouze existuje
> > per session. Abys nebyl zklamany.
> 
>  Tomu nerozumim. Obsah tabulky neni per session, ale tabulka samotna 
>  per session je? 

Od temporary tabulky bych tak nejak ocekaval, ze ji jednou vyrobim (to
je DDL operace, takze to by mel delat nekdo s dostatecne vysokymi
pravy), ona bude existovat, ale kazda session bude zacinat s cistym
obsahem. A uzivatele (s DML pravy) v ni budou pracovat. V PostgreSQL
ovsem ta tabulka po skonceni session zmizi.

>  Ostatne stejne zklaman by mohl byt clovek pri prechodu na DB2, Informix
>  nebo na pri prechodu z xbase ;-)  Pro mne je u Oracle zklamanim, ze pri
>  debatach v konferenci nemuzu podivat do zdrojaku jek je tam co udelano.

No, tohle nema byt co zklamanim, protoze tohle jaksi predem vis.
Zatimco PostgreSQL ma podporu spousty proceduralnich jazyku, ale minimalne
v tom "nativnim" (PL/pgSQL) se nedaji pekne udelat promenne pouzitelne
pri behu jednoho databazoveho spojeni (tedy Oracli package).

Abych jen tak neteoretizoval, uvedu priklad, kde to pouzivam a kde mi
to vadi, treba nekdo bude vedet elegantni reseni:

Uzivatele klikaji autentizovane na Webu. Chci u jednotlivych zmen
v databazi logovat, kdo tu zmenu udelal. Do databaze ten aplikacni
server jde pod jednim uzivatelem. Chtel bych nejlepe jeste pred
spustenim toho aplikacniho handleru nastavit nejakou promennou v tom
databazovem spojeni, ktera by se pak pouzila ve vsech tedy insert /
update / delete triggerech jako hodnota prave prihlaseneho vzdaleneho
uzivatele a predala do logovacich tabulek.

Nejblize, jak jsem se dostal k reseni, je pokazde testovat, jestli
uz dana pomocna tabulka existuje (protoze jsem ji mohl zdedit
s presistentnim db spojenim), pokud ne, tak ji vytvorit, commitnout,
ulozit hodnotu, a pouzivat. A ty manipulace s ni musim delat pres
execute '', protoze primy select se chytne na nejaky interni
identifikator, ktery o kousek dal uz neexistuje. Oc jednodussi by
to bylo, kdybych vedel, ze ta tabulka vzdy bude existovat, protoze
jsem ji jednou v ramci vytvareni datoveho schematu vytvoril,
dokonce bych si nad ni mohl udelat primarni klice a foreign klice
a tak, a kazda session by do ni pouze dala aktualni data.

A co treba ruzna trideni? Jak se to da v PostgreSQL rozumne
udelat? Ano, pouziti locales je fajn, jenze co se stane, kdyz
zupgraduju glibc-common a jako na potvoru tam definice locales bude
trosku jina? Rekl bych, ze mi to rozpadne indexy. Nehlede na to, ze by
fakt vcelku rad jednou delal order by anglicky a jednou cesky -- tuhle
se tady na to nekdo ptal a odpoved provest initdb se spravnym
LC_COLLATE neni uplne to prave orechove. V Oraclu je to parametr
klienta (NLS_SORT), menitelny, plus jeste kazdy order by muze pouzit
svoje nls nastaveni. Co PostgreSQL? Skoro uvazuju, ze budu muset
sednout a naportovat do PostgreSQL svou radici rutinu z MySQL.
Alternativne by se to mozna dalo napsat i pomoci strxfrm, aby to bylo
kompatibilni s localovym PostgreSQLim pristupem. Jen me prekvapuje,
ze odpovedi jsou vesmes "udelej spravne initdb", misto aby vyvojari
rekli, ze radit podle ruznych kriterii neni uplne nesmyslny napad
a ze to nema co byt zadratovany parametr databazove instalace.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From kluvanek na tesnet.cz  Wed Feb 25 16:16:00 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Wed, 25 Feb 2004 16:16:00 +0100
Subject: Transakcnost DDL & Oracle (Re: ako synchronizovat databazove
 skupiny podla tabulky?)
In-Reply-To: <403C6339.3090704@pikebo.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz>
Message-ID: <403CBC30.6080606@trb.tesnet.cz>

Jan Serak napsal(a):

> Honza Pazdziora wrote:
> 
>> On Tue, Feb 24, 2004 at 07:29:25AM +0100, Jan Serak wrote:
>>
>>>> pouzivam postgresql verzie 7.4.1.
>>>
>>>
>>> Postgresql neznam, odpoved bude obecna.
>>
>>
>>
>> Praveze ne. To, ze Oracle po DDL operaci dela commit neznamena, ze
>> to je obecny princip.
> 
> 
> Vypada to, ze jsem v praxi perfektne ukazal, jak vypadaji myslenkova 
> klise, o nichz jsem tu psal nedavno (browse velke tabulky). Moc se za to 
> omlouvam vsem, ktere jsem svym prispevkem zmatl.
> 
> Kdyz nad tim ted uvazuju, tak zkousim najit duvod nebo priklad situace, 
> kdy nelze po uspesnem provedeni DDL prikazu zmeny odvolat. Bez uspechu.
> Teoreticky tomu tedy vubec nic nevadi.
> 
> Proc ale Oracle implementoval DDL tak, ze kazdy prikaz je samostatna 
> transakce? Kdyz pominu jako duvod ojebavku, vzletne oznacovanou jako 
> "limitation", tak jediny duvod je pruchodnost databaze (pripadne zmeny v 
> datech se nemusi delat pres rollback segment).
No ano ale stejne (viz nasa diskusia pred cca 3 mesiacmi) je zas humus ze DML 
prikazy MUSIA ist cez rollback/redo/archivne logy i ked to nechcem.
DDL nejde rolback a DML zas ide natvrdo. (pokial nechcem zakladat dalsiu 
databazu s inym vychodzim nastavenim )
:-(
> 
> Kazdopadne tohle byla posledni kapka, ktera me donuti ten zazracny 
> PostreSQL nainstalovat ;-)
> 
> Jan Serak
> 
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From zakkr na zf.jcu.cz  Wed Feb 25 16:51:24 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Wed, 25 Feb 2004 16:51:24 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040225143853.GI25426@anxur.fi.muni.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz>
Message-ID: <20040225155124.GF29814@zf.jcu.cz>

On Wed, Feb 25, 2004 at 03:38:53PM +0100, Honza Pazdziora wrote:
> Od temporary tabulky bych tak nejak ocekaval, ze ji jednou vyrobim (to
> je DDL operace, takze to by mel delat nekdo s dostatecne vysokymi
> pravy), ona bude existovat, ale kazda session bude zacinat s cistym
> obsahem. A uzivatele (s DML pravy) v ni budou pracovat. V PostgreSQL
> ovsem ta tabulka po skonceni session zmizi.

 Hmm, pokud  je mi znamo  tak zadny  standard nic takoveho  nedefinuje a
 proste v  PostgreSQL plati,  ze docasnost  je dana  prave session. IMHO
 todle je to co jsem nedavno  kritizovali u debaty s xbase -- ocekavani,
 ze  "spravne" je  to na  co jsem  doposud navyknuty. Treba  me soucasne
 chovani vyhovuje.

> No, tohle nema byt co zklamanim, protoze tohle jaksi predem vis.
> Zatimco PostgreSQL ma podporu spousty proceduralnich jazyku, ale minimalne
> v tom "nativnim" (PL/pgSQL) se nedaji pekne udelat promenne pouzitelne

 Ja osobne PLSQL povazuji za pokus jak  tem co se jednou naucili SQL dat
 moznost  delat v  "temer  SQL"  to co  SQL  neumi. Pokud  to srovnam  s
 libovolnym jinym  jazykem tak je  to dost krkolomny  a ja osobne  v tom
 pisu jen nekolikaradkove veci.

 Jinak uznavam, ze Oracle je v na tom s funkcema lepe.

> Uzivatele klikaji autentizovane na Webu. Chci u jednotlivych zmen
> v databazi logovat, kdo tu zmenu udelal. Do databaze ten aplikacni
> server jde pod jednim uzivatelem. Chtel bych nejlepe jeste pred

 Jde pomoci  SET SESSION  AUTHORIZATION <user> prepinat  pod superuserem
 na  jine  uzivatele. Funkce  getpgusername()  pak  vraci  jmeno  usera.
 Pochopitelne v rade pripadu kde interface_user != DB_user je to na nic.

> spustenim toho aplikacniho handleru nastavit nejakou promennou v tom
> databazovem spojeni, ktera by se pak pouzila ve vsech tedy insert /
> update / delete triggerech jako hodnota prave prihlaseneho vzdaleneho
> uzivatele a predala do logovacich tabulek.
> 
> Nejblize, jak jsem se dostal k reseni, je pokazde testovat, jestli
> uz dana pomocna tabulka existuje (protoze jsem ji mohl zdedit
> s presistentnim db spojenim), pokud ne, tak ji vytvorit, commitnout,
> ulozit hodnotu, a pouzivat. A ty manipulace s ni musim delat pres
> execute '', protoze primy select se chytne na nejaky interni
> identifikator, ktery o kousek dal uz neexistuje. Oc jednodussi by
> to bylo, kdybych vedel, ze ta tabulka vzdy bude existovat, protoze
> jsem ji jednou v ramci vytvareni datoveho schematu vytvoril,
> dokonce bych si nad ni mohl udelat primarni klice a foreign klice
> a tak, a kazda session by do ni pouze dala aktualni data.

 Takze nakonec  to reseni ma a  jedina vada na krase  je nutnost zjistit
 jsem-li prvni v  dane session nebo ne -- coz  muze celkem snadno udelat
 klient co  zaklada tu session  a po  navazani spojeni mimo  jinych veci
 nainicializuje i  tu potrebnou  temp tabulku. Ty  rutiny co  tu tabulku
 pouzivaji nic zjistovat nemuseji. IMHO je to problem logiky aplikace.

> A co treba ruzna trideni? Jak se to da v PostgreSQL rozumne

 Ano to je vetsi problem.

> udelat? Ano, pouziti locales je fajn, jenze co se stane, kdyz
> zupgraduju glibc-common a jako na potvoru tam definice locales bude
> trosku jina? Rekl bych, ze mi to rozpadne indexy. Nehlede na to, ze by

 Jo, ale to  znamena vykaslat se na systemove locales  a udelat vlastni.
 Coz uz v konferencich PostgreSQL zaznelo a podle mne to tak i dopadne.

> fakt vcelku rad jednou delal order by anglicky a jednou cesky -- tuhle
> se tady na to nekdo ptal a odpoved provest initdb se spravnym
> LC_COLLATE neni uplne to prave orechove. V Oraclu je to parametr
> klienta (NLS_SORT), menitelny, plus jeste kazdy order by muze pouzit
> svoje nls nastaveni. Co PostgreSQL? Skoro uvazuju, ze budu muset
> sednout a naportovat do PostgreSQL svou radici rutinu z MySQL.
> Alternativne by se to mozna dalo napsat i pomoci strxfrm, aby to bylo
> kompatibilni s localovym PostgreSQLim pristupem. Jen me prekvapuje,
> ze odpovedi jsou vesmes "udelej spravne initdb", misto aby vyvojari
> rekli, ze radit podle ruznych kriterii neni uplne nesmyslny napad
> a ze to nema co byt zadratovany parametr databazove instalace.

 Pouzivani ruznych locales neni nesmysl a  urcite se o tom uvazuje.  Jen
 proste udelat nejake systemove reseni neni uplne trivialni a pri vyvoji
 PostgreSQL se vetsinou jine reseni  nedelaji, a nez nejaky necisty hack
 tak radeji nekolik release nic...

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From Janousek na FoNet.Cz  Wed Feb 25 16:59:27 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Wed, 25 Feb 2004 16:59:27 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040225155124.GF29814@zf.jcu.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A94@percival.fonet.cz>

> -----Original Message-----
> From: Karel Zak [mailto:zakkr na zf.jcu.cz] 
>  PostgreSQL se vetsinou jine reseni  nedelaji, a nez nejaky 
> necisty hack
>  tak radeji nekolik release nic...

	K tomuto bych rad podotkl, ze prave tuto vlastnost na PostgreSQL
ocenuji (mozna nejsem sam), mozna to je zpatecnicke, mozna jsem
dinosaurus (to radsi nez pojidac kolacu<g>), ale opravdu pri vyvoji
vetsiho celku nejde delat krkolomne obratky kazdou verzi, nerknu-li
kazdy release (tak jak nam to treba predvani PHP, coby tak vyzdvihovany
"Web" jazyk).

	Ja si take rovnez radeji pockam na systemove reseni, u ktereho
mam mimo jine zpravidla zaruceno (a ja tomu verim), ze nez se to
systemove reseni navrhlo a implementovalo, ze nad tim vice lidi docela
dlouho premyslelo a syntetizovalo. Takze vyvoj neni zpusobem, takto by
to mohlo jit, zkusime a uvidime, treba to bude stacit...

	I mne dneska chybi moznost jednoduche replikace, ktera je
slibovana uz od verze 6.X (ne-li dele => vice jak 5 let). Radsi si
pockam, nez pak vsechny aplikace upravovat dle aktualne platne semantiky
replikacniho clusteru.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From sherry na pikebo.cz  Wed Feb 25 17:56:02 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Wed, 25 Feb 2004 17:56:02 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz> <20040225155124.GF29814@zf.jcu.cz>
Message-ID: <403CD3A2.1090203@pikebo.cz>

Karel Zak wrote:
> On Wed, Feb 25, 2004 at 03:38:53PM +0100, Honza Pazdziora wrote:
>>No, tohle nema byt co zklamanim, protoze tohle jaksi predem vis.
>>Zatimco PostgreSQL ma podporu spousty proceduralnich jazyku, ale minimalne
>>v tom "nativnim" (PL/pgSQL) se nedaji pekne udelat promenne pouzitelne
> 
> 
>  Ja osobne PLSQL povazuji za pokus jak  tem co se jednou naucili SQL dat
>  moznost  delat v  "temer  SQL"  to co  SQL  neumi. Pokud  to srovnam  s
>  libovolnym jinym  jazykem tak je  to dost krkolomny  a ja osobne  v tom
>  pisu jen nekolikaradkove veci.

PL/SQL, resp. prave ta proceduralni nastavba, je stara jako Metuzalem, 
od Oracle6 (1993) v podstate nezmemena. Jeho rysy (in, out a inout 
parametry, vyjimky, procedury definovane uvnitr procedur,...) jsou 
prevzaty z Ady, rozhodne to neni zadna ulitba ve stylu "at je to co 
nejpodobnejsi SQL".

A krkolomne to rozhodne neni. Neinteraktivni ulohy se v tom vyvijeji 
velice rychle a velice snadno, mj. proto, ze se nemusi oprogramovavat 
predavani hodnot mezi SQL a promennymi v proceduralni nadstavbe, coz je 
velice krkolomne v hybridu SQL a C (zvanem Pro*C), a v OCI, ODBC a JDBC 
strasne rozvlekle.

Dukazem necht je jeden z nasich projektu, ktery ma 30000 radku PL/SQL 
(pouze v packagich), z cehoz 7 kousku je nad 1000 a 3 kousky nad 3000 radku.

Jan Serak



From adelton na informatics.muni.cz  Wed Feb 25 18:07:07 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Wed, 25 Feb 2004 18:07:07 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040225155124.GF29814@zf.jcu.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz> <20040225155124.GF29814@zf.jcu.cz>
Message-ID: <20040225170707.GJ25426@anxur.fi.muni.cz>

On Wed, Feb 25, 2004 at 04:51:24PM +0100, Karel Zak wrote:
> 
>  Hmm, pokud  je mi znamo  tak zadny  standard nic takoveho  nedefinuje a
>  proste v  PostgreSQL plati,  ze docasnost  je dana  prave session. IMHO
>  todle je to co jsem nedavno  kritizovali u debaty s xbase -- ocekavani,
>  ze  "spravne" je  to na  co jsem  doposud navyknuty. Treba  me soucasne
>  chovani vyhovuje.

Chapu vytku. Nicmene mi prijde logicke, ze nekdo vytvari databazove
objekty (DDL) a nekdo jiny je pouziva (DML). A ze pokud soucasti
datoveho schematu ma byt nejaka pomocna tabulka, tak ze bude vytvorena
jednou.

Navic, standard tu semantiku popisuje a i dokumentace PostgreSQL
jasne rika, ze se v tomto od standardu odlisuje:

	Although the syntax of CREATE TEMPORARY TABLE resembles that
	of the SQL standard, the effect is not the same. In the
	standard, temporary tables are defined just once and
	automatically exist (starting with empty contents) in every
	session that needs them.
	[...]

>  Takze nakonec  to reseni ma a  jedina vada na krase  je nutnost zjistit
>  jsem-li prvni v  dane session nebo ne -- coz  muze celkem snadno udelat
>  klient co  zaklada tu session  a po  navazani spojeni mimo  jinych veci
>  nainicializuje i  tu potrebnou  temp tabulku. Ty  rutiny co  tu tabulku
>  pouzivaji nic zjistovat nemuseji. IMHO je to problem logiky aplikace.

Ano, i tak se na to da nahlizet. Ovsem ten databazovy handle mohu sebrat
odkudkoli, takze se na to v mem konkretnim pripade neda spolehat.

>  Pouzivani ruznych locales neni nesmysl a  urcite se o tom uvazuje.  Jen
>  proste udelat nejake systemove reseni neni uplne trivialni a pri vyvoji
>  PostgreSQL se vetsinou jine reseni  nedelaji, a nez nejaky necisty hack
>  tak radeji nekolik release nic...

Takze jo. Sedl jsem a napsal to, vysledek je, ze

test=# select name from tst order by nls_string(name, 'en_US.UTF-8');
   name
----------
 chrt
 hrnec
 japonec
 Japonec
 Japonsko
 japonsky
 japonský
(7 rows)
 
test=# select name from tst order by nls_string(name, 'cs_CZ.UTF-8');
   name
----------
 hrnec
 chrt
 Japonec
 japonec
 Japonsko
 japonsky
 japonský
(7 rows)

Jeste to ale pada, predpokladam, ze budu muset zapracovat na tom,
aby to vsechno bylo thread safe, nebo tak. Ma cenu to nekam posilat?
 
-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From kluvanek na tesnet.cz  Wed Feb 25 18:27:17 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Wed, 25 Feb 2004 18:27:17 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
In-Reply-To: <403CD3A2.1090203@pikebo.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz> <20040225155124.GF29814@zf.jcu.cz> <403CD3A2.1090203@pikebo.cz>
Message-ID: <403CDAF5.80306@trb.tesnet.cz>

Jan Serak napsal(a):
> Karel Zak wrote:
> 
>> On Wed, Feb 25, 2004 at 03:38:53PM +0100, Honza Pazdziora wrote:
>>
>>> No, tohle nema byt co zklamanim, protoze tohle jaksi predem vis.
>>> Zatimco PostgreSQL ma podporu spousty proceduralnich jazyku, ale 
>>> minimalne
>>> v tom "nativnim" (PL/pgSQL) se nedaji pekne udelat promenne pouzitelne
>>
>>
>>
>>  Ja osobne PLSQL povazuji za pokus jak  tem co se jednou naucili SQL dat
>>  moznost  delat v  "temer  SQL"  to co  SQL  neumi. Pokud  to srovnam  s
>>  libovolnym jinym  jazykem tak je  to dost krkolomny  a ja osobne  v tom
>>  pisu jen nekolikaradkove veci.
> 
> 
> PL/SQL, resp. prave ta proceduralni nastavba, je stara jako Metuzalem, 
> od Oracle6 (1993) v podstate nezmemena. Jeho rysy (in, out a inout 
> parametry, vyjimky, procedury definovane uvnitr procedur,...) jsou 
> prevzaty z Ady, rozhodne to neni zadna ulitba ve stylu "at je to co 
> nejpodobnejsi SQL".
Lenze v tom stejne nejde niekedy spravit ani tie najtrivialnejsie veci. Hlavne v 
smere na filesystem.


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From kluvanek na tesnet.cz  Wed Feb 25 18:38:02 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Wed, 25 Feb 2004 18:38:02 +0100
Subject: identifikacia uzivatela (Re: PostgreSQL a temporary tabulky a trideni)
In-Reply-To: <20040225143853.GI25426@anxur.fi.muni.cz>
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz>
Message-ID: <403CDD7A.4080106@trb.tesnet.cz>

> Uzivatele klikaji autentizovane na Webu. Chci u jednotlivych zmen
> v databazi logovat, kdo tu zmenu udelal. Do databaze ten aplikacni
> server jde pod jednim uzivatelem. Chtel bych nejlepe jeste pred
> spustenim toho aplikacniho handleru nastavit nejakou promennou v tom
> databazovem spojeni, ktera by se pak pouzila ve vsech tedy insert /
> update / delete triggerech jako hodnota prave prihlaseneho vzdaleneho
> uzivatele a predala do logovacich tabulek.
> 
> Nejblize, jak jsem se dostal k reseni, je pokazde testovat, jestli
> uz dana pomocna tabulka existuje (protoze jsem ji mohl zdedit
> s presistentnim db spojenim), pokud ne, tak ji vytvorit, commitnout,
> ulozit hodnotu, a pouzivat. A ty manipulace s ni musim delat pres
> execute '', protoze primy select se chytne na nejaky interni
> identifikator, ktery o kousek dal uz neexistuje. Oc jednodussi by
> to bylo, kdybych vedel, ze ta tabulka vzdy bude existovat, protoze
> jsem ji jednou v ramci vytvareni datoveho schematu vytvoril,
> dokonce bych si nad ni mohl udelat primarni klice a foreign klice
> a tak, a kazda session by do ni pouze dala aktualni data.

Tiez som to riesil a nevyriesil.
Rad by som idy uzivatelov ktory poreviedli modifikaciu niekde proitokoloval. 
Najistejsie by to bolo priamo triggermi, lenze odkial do prcic sa ma trigger 
dozvediet, kto to bol, ked k tomu z hladiska DB stroja lezie vzdy DBuser s menom 
WebUser. Ta WEB aplikacia sice vie, kto je user, ale ako to povie triggeru?
Navyse aby to bolo zaujimave, tak ta aplikacia z nejakeho mne neznameho dovodu 
nepouziva persistentne spojenia ale kazde okno/dialog si otvara nove, takze je 
asi tazko nieco zakladat na zamykani zamkov alebo transakciach...

Jedina moznost s detekciou koncoveho uzivatela by asi bola zakazdym pri otvarani 
session vyplnit/zalozit TEMP tabulku s IDom uzivatela...?
No ale to uz pomaly zacina byt pekny humac, ked si predstavim, ze to je pri 
kazdom prechode odniekial niekam...

-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From horak na sitmp.cz  Thu Feb 26 06:51:43 2004
From: horak na sitmp.cz (=?iso-8859-1?Q?Hor=E1k_Daniel?=)
Date: Thu, 26 Feb 2004 06:51:43 +0100
Subject: PostgreSQL a temporary tabulky a trideni
Message-ID: <66EFFC1A2B0A424E87D68EC10B1F458D03DAB9@EXCH2.mmp.plzen-city.cz>

> >  Pouzivani ruznych locales neni nesmysl a  urcite se o tom 
> uvazuje.  Jen
> >  proste udelat nejake systemove reseni neni uplne trivialni 
> a pri vyvoji
> >  PostgreSQL se vetsinou jine reseni  nedelaji, a nez nejaky 
> necisty hack
> >  tak radeji nekolik release nic...
> 
> Takze jo. Sedl jsem a napsal to, vysledek je, ze
> 
> test=# select name from tst order by nls_string(name, 'en_US.UTF-8');
>    name
> ----------
>  chrt
>  hrnec
>  japonec
>  Japonec
>  Japonsko
>  japonsky
>  japonský
> (7 rows)
>  
> test=# select name from tst order by nls_string(name, 'cs_CZ.UTF-8');
>    name
> ----------
>  hrnec
>  chrt
>  Japonec
>  japonec
>  Japonsko
>  japonsky
>  japonský
> (7 rows)
> 
> Jeste to ale pada, predpokladam, ze budu muset zapracovat na tom,
> aby to vsechno bylo thread safe, nebo tak. Ma cenu to nekam posilat?

To vypada dost slibne. Thread-safe to byt nemusi, pokud je to modul
natahovany do backendu (coz nejspis je).

A urcite bych se s tim v pgsql-hackers pochlubil. Muze to pomoct spouste
lidi, protoze, jak uz psal Karel, bude potreba napsat (nebo najit s
pouzitelnou licenci) vlastni implementaci locales.


			Dan

From Ales.Zika na pel.br.ds.mfcr.cz  Thu Feb 26 07:17:44 2004
From: Ales.Zika na pel.br.ds.mfcr.cz (=?iso-8859-2?Q?=22Z=EDka_Ale=B9=2C_Ing=2E=22?=)
Date: Thu, 26 Feb 2004 07:17:44 +0100
Subject: PostgreSQL a temporary tabulky a trideni
Message-ID: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz>


> Takze jo. Sedl jsem a napsal to, vysledek je, ze
> 
> test=# select name from tst order by nls_string(name, 'en_US.UTF-8');
>    name
> ----------
>  chrt
>  hrnec
>  japonec
>  Japonec
>  Japonsko
>  japonsky
>  japonský
> (7 rows)
>  
> test=# select name from tst order by nls_string(name, 'cs_CZ.UTF-8');
>    name
> ----------
>  hrnec
>  chrt
>  Japonec
>  japonec
>  Japonsko
>  japonsky
>  japonský
> (7 rows)
> 
> Jeste to ale pada, predpokladam, ze budu muset zapracovat na tom,
> aby to vsechno bylo thread safe, nebo tak. Ma cenu to nekam posilat?
>  


	No jasne, sem s tim !!!
	Pred par tydny jsem si tu stezoval, ze mi databaze u providera na
webu blbe tridi cestinu a z reakci tak nejak vyplynulo, ze mam nejspis
smulu...

	
			Ales Zika
			CSE Spoje Pelhrimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz 

From stehule na kix.fsv.cvut.cz  Thu Feb 26 08:04:45 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 26 Feb 2004 08:04:45 +0100 (CET)
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
In-Reply-To: <403CDAF5.80306@trb.tesnet.cz>
Message-ID: <Pine.LNX.4.44.0402260801050.28832-100000@kix.fsv.cvut.cz>

> Lenze v tom stejne nejde niekedy spravit ani tie najtrivialnejsie veci. Hlavne v 
> smere na filesystem.
> 
Ono by se tam ani s FileSystemem delat nemelo. Pokud je mi znamo, tak 
Oracle ale ma package na operace se souborovym systemem. Do Pl/pgSQL je 
lze doplnit, cca po za hodinku programovani si zpristupnite api. Problem 
je s uvolnovanim descriptoru souboru pri pripadne chybe v procedure, 
jelikoz PostgreSQL nezna pro custom datove typy destruktor.

Pavel


From sherry na pikebo.cz  Thu Feb 26 08:58:15 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Thu, 26 Feb 2004 08:58:15 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
References: <200402232245.47553.mkundrat@penguin.cz> <403AEF45.3060103@pikebo.cz> <20040224083742.GA29071@anxur.fi.muni.cz> <403C6339.3090704@pikebo.cz> <20040225103153.GC25426@anxur.fi.muni.cz> <20040225141625.GE29814@zf.jcu.cz> <20040225143853.GI25426@anxur.fi.muni.cz> <20040225155124.GF29814@zf.jcu.cz> <403CD3A2.1090203@pikebo.cz> <403CDAF5.80306@trb.tesnet.cz>
Message-ID: <403DA717.7040606@pikebo.cz>

Kluvanek Martin wrote:
> Jan Serak napsal(a):
>> PL/SQL, resp. prave ta proceduralni nastavba, je stara jako Metuzalem, 
>> od Oracle6 (1993) v podstate nezmemena. Jeho rysy (in, out a inout 
>> parametry, vyjimky, procedury definovane uvnitr procedur,...) jsou 
>> prevzaty z Ady, rozhodne to neni zadna ulitba ve stylu "at je to co 
>> nejpodobnejsi SQL".
> 
> Lenze v tom stejne nejde niekedy spravit ani tie najtrivialnejsie veci. 
> Hlavne v smere na filesystem.

Vzhledem k tomu, ze filesystem neni soucasti prostredi, v nemz je PL/SQL 
interpretovano, tak bych to nepovazoval za trivialni vec. Vyresit 
pristup na filesystem v javove aplikaci bezici na mobilnim telefonu asi 
taky nebude z nejjednodussich ;-)

Pri nutnosti menit data v databazi i na filesystemu soucasne rozhodne 
nelze doporucit PL/SQL. Sice Oracle dodava package UTL_FILE, ale jeji 
pouziti prinasi vic problemu nez uzitku. Na nejaky ten prototyping se 
mozna hodi (prototyp je napsan velice rychle), ale na kriticke moduly 
tohoto typu nestaci (pomalost, problemy s pristupovymi pravy,...) a je 
nutno to napsat v OCI (pro toho, kdo si troufa primo urcovat, kdy se ma 
SQL prikaz parsovat, atd.) nebo Pro*C (pro toho, kdo si troufa zvladnout 
toto strasne necitelne prostredi).

Jan Serak



From Janousek na FoNet.Cz  Thu Feb 26 09:13:14 2004
From: Janousek na FoNet.Cz (Ing. Pavel Janousek)
Date: Thu, 26 Feb 2004 09:13:14 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
In-Reply-To: <403DA717.7040606@pikebo.cz>
Message-ID: <4F23E9745D562F4D90373B9C5CEF4430178A97@percival.fonet.cz>

> -----Original Message-----
> From: Jan Serak [mailto:sherry na pikebo.cz] 
> SQL prikaz parsovat, atd.) nebo Pro*C (pro toho, kdo si 
> troufa zvladnout 
> toto strasne necitelne prostredi).

	Co mate proti Pro*C (ony jsou/byly i pro jine jazyky) pripadne
ESQL v PostgreSQL?

	Uznavam, ze je treba pochopit filosofii, ale pokud je nekdo
happy z pouziti 'libpgsql', pripadne si jak v raji...:-)

	Pravda pokud je nekdo zvykly na designer ci Pl/SQL nepricichne k
tomu s nadsenim.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------


From adelton na informatics.muni.cz  Thu Feb 26 09:26:05 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Thu, 26 Feb 2004 09:26:05 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz>
Message-ID: <20040226082605.GA1680@anxur.fi.muni.cz>

On Thu, Feb 26, 2004 at 07:17:44AM +0100, "Zíka Aleš, Ing." wrote:
> 
> 	No jasne, sem s tim !!!
> 	Pred par tydny jsem si tu stezoval, ze mi databaze u providera na
> webu blbe tridi cestinu a z reakci tak nejak vyplynulo, ze mam nejspis
> smulu...

http://www.fi.muni.cz/~adelton/l10n/
http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string-0.50.tar.gz

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From adelton na informatics.muni.cz  Thu Feb 26 09:27:06 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Thu, 26 Feb 2004 09:27:06 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <66EFFC1A2B0A424E87D68EC10B1F458D03DAB9@EXCH2.mmp.plzen-city.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DAB9@EXCH2.mmp.plzen-city.cz>
Message-ID: <20040226082706.GB1680@anxur.fi.muni.cz>

On Thu, Feb 26, 2004 at 06:51:43AM +0100, Horák Daniel wrote:
> 
> To vypada dost slibne. Thread-safe to byt nemusi, pokud je to modul

Jo, problem byl jinde, vyreseno.

> A urcite bych se s tim v pgsql-hackers pochlubil. Muze to pomoct spouste
> lidi, protoze, jak uz psal Karel, bude potreba napsat (nebo najit s
> pouzitelnou licenci) vlastni implementaci locales.

Ovsem na to, aby clovek mohl poslat neco do pgsql-hackers, tam nejspis
bude muset byt prihlaseny, co?

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From sherry na pikebo.cz  Thu Feb 26 09:23:30 2004
From: sherry na pikebo.cz (Jan Serak)
Date: Thu, 26 Feb 2004 09:23:30 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
References: <4F23E9745D562F4D90373B9C5CEF4430178A97@percival.fonet.cz>
Message-ID: <403DAD02.6000304@pikebo.cz>

Ing. Pavel Janousek wrote:
> 	Co mate proti Pro*C (ony jsou/byly i pro jine jazyky) pripadne
> ESQL v PostgreSQL?

Me Pro*C silne nevyhovuje, to je muj osobni nazor, ktery nehodlam 
priznivcum Pro*C vnucovat. Jistou dobu jsem musel udrzovat Pro*C modul a 
nebyl jsem z nej moc stastny a rad jsem se jej zbavil. Rozhodne jsem 
nikdy neziskal odvahu v Pro*C sam neco noveho napsat. OCI je pro me 
primocarejsi a pohled na zdrojaky "homogennejsi".

Jan Serak



From zakkr na zf.jcu.cz  Thu Feb 26 10:22:16 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 26 Feb 2004 10:22:16 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226082605.GA1680@anxur.fi.muni.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz>
Message-ID: <20040226092216.GA6949@zf.jcu.cz>

On Thu, Feb 26, 2004 at 09:26:05AM +0100, Honza Pazdziora wrote:
> On Thu, Feb 26, 2004 at 07:17:44AM +0100, "Zíka Aleš, Ing." wrote:
> > 
> > 	No jasne, sem s tim !!!
> > 	Pred par tydny jsem si tu stezoval, ze mi databaze u providera na
> > webu blbe tridi cestinu a z reakci tak nejak vyplynulo, ze mam nejspis
> > smulu...
> 
> http://www.fi.muni.cz/~adelton/l10n/
> http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string-0.50.tar.gz

 Muzu tam udelat par zmen a pripadne to tlacit do PostgreSQL?

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Thu Feb 26 10:28:15 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Thu, 26 Feb 2004 10:28:15 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226092216.GA6949@zf.jcu.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz> <20040226092216.GA6949@zf.jcu.cz>
Message-ID: <20040226092815.GF1680@anxur.fi.muni.cz>

On Thu, Feb 26, 2004 at 10:22:16AM +0100, Karel Zak wrote:
> > 
> > http://www.fi.muni.cz/~adelton/l10n/
> > http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string-0.50.tar.gz
> 
>  Muzu tam udelat par zmen a pripadne to tlacit do PostgreSQL?

Jiste. Je to free software.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From zakkr na zf.jcu.cz  Thu Feb 26 10:40:35 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 26 Feb 2004 10:40:35 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226092815.GF1680@anxur.fi.muni.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz> <20040226092216.GA6949@zf.jcu.cz> <20040226092815.GF1680@anxur.fi.muni.cz>
Message-ID: <20040226094035.GB6949@zf.jcu.cz>

On Thu, Feb 26, 2004 at 10:28:15AM +0100, Honza Pazdziora wrote:
> On Thu, Feb 26, 2004 at 10:22:16AM +0100, Karel Zak wrote:
> > > 
> > > http://www.fi.muni.cz/~adelton/l10n/
> > > http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string-0.50.tar.gz
> > 
> >  Muzu tam udelat par zmen a pripadne to tlacit do PostgreSQL?
> 
> Jiste. Je to free software.

 OK. Autorstvi bude zachovano:-)
 
 Jinak pro zajimavost,  protoze se o tom moc nevi  -- volani setlocale()
 typu:
 
    org = setlocale(ctg, NULL);

    setlocale(ctg, moje_locale);

    setlocale(ctg, org);

 Je  neportovatelne   a  na   nekterych  platformach  muze   delat  neco
 neocekavatelneho,  protoze  setlocale()  tam  muze  vracet  pointer  na
 staticky buffer kde jen prepisuje obsah. Lepsi je tedy hodnotu vracenou
 setlocale() kterou si chci zapamatovat pred volanim dalsiho setlocale()
 realokovat.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Thu Feb 26 10:45:17 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Thu, 26 Feb 2004 10:45:17 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226094035.GB6949@zf.jcu.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz> <20040226092216.GA6949@zf.jcu.cz> <20040226092815.GF1680@anxur.fi.muni.cz> <20040226094035.GB6949@zf.jcu.cz>
Message-ID: <20040226094517.GG1680@anxur.fi.muni.cz>

On Thu, Feb 26, 2004 at 10:40:35AM +0100, Karel Zak wrote:
>  
>  Jinak pro zajimavost,  protoze se o tom moc nevi  -- volani setlocale()
>  typu:
>  
>     org = setlocale(ctg, NULL);
> 
>     setlocale(ctg, moje_locale);
> 
>     setlocale(ctg, org);
> 
>  Je  neportovatelne   a  na   nekterych  platformach  muze   delat  neco
>  neocekavatelneho,  protoze  setlocale()  tam  muze  vracet  pointer  na
>  staticky buffer kde jen prepisuje obsah. Lepsi je tedy hodnotu vracenou
>  setlocale() kterou si chci zapamatovat pred volanim dalsiho setlocale()
>  realokovat.

Aha, OK. Hmmm.

Dalsi moznost je asi ulozit si tu puvodni hodnotu pouze poprve, protoze
ona se asi nema co menit, v prubehu zivota toho backendu. Nebo minimalne
usetrit tak, ze se znovupouzije jedinkrat naalokovany buffer.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From morgaider na sissify.com  Thu Feb 26 13:44:37 2004
From: morgaider na sissify.com (Stacey Vaughan)
Date: Thu, 26 Feb 2004 07:44:37 -0500
Subject: TAKE A STEP Into The Rx Future, spice digram vaccinate flycatcher
Message-ID: <PELIOJUFTYSYBMZQLIHTED@mive.co.kr>

Wholesale Rx

Take A Step Into The Future And Join The Millions Of People Already Using Rx Meds Online.

http://www.more-salz.com/jw/


Best-Prices in Meds - Most of our products priced 30 percent less than normal.

http://www.more-salz.com/jw/


No Prior Rx Required - Shipped-Direct to Your Door - U.S. Licensed Doctors.

http://www.more-salz.com/jw/


No thanks: http://www.more-salz.com/postmark.html

artifact

wilma costume mood rubidium barnet vis carolingian perceptual todd muskox kresge silkworm meanwhile clipboard dim primp berglund oxidate antigone fastidious bianco dahl bibliophile corset large scription el scylla tacit superfluity ringside concerto jure such delouse solipsism trough 

From kluvanek na tesnet.cz  Thu Feb 26 14:08:16 2004
From: kluvanek na tesnet.cz (Kluvanek Martin)
Date: Thu, 26 Feb 2004 14:08:16 +0100
Subject: PL/SQL (Re: PostgreSQL a temporary tabulky a trideni)
In-Reply-To: <Pine.LNX.4.44.0402260801050.28832-100000@kix.fsv.cvut.cz>
References: <Pine.LNX.4.44.0402260801050.28832-100000@kix.fsv.cvut.cz>
Message-ID: <403DEFC0.3030008@trb.tesnet.cz>

Pavel Stehule napsal(a):

>>Lenze v tom stejne nejde niekedy spravit ani tie najtrivialnejsie veci. Hlavne v 
>>smere na filesystem.
>>
> 
> Ono by se tam ani s FileSystemem delat nemelo. Pokud je mi znamo, tak 
> Oracle ale ma package na operace se souborovym systemem. 
Prave ze to tam naozaj je, az nato, ze ked sa nachytate, tak zistite, ze to tam 
defacto vlastne neni, pretoze to nevie spustu veci, ktore by to v navaznosti na 
BFILE vediet malo.
Naco mi je datovy typ BFILE, ked k nemu nemam ani tie najtrivialnejsie moznosti 
na spravovanie. To si to potom mozem vsetko robit stejne sam a v DB mat ulozene 
len meno suboru.
To ze to nedotiahli ani do zakladneho konca je dost velka chyba. Takto by som 
doporedu ratal s tym, ze tam vlastne ziadna podpora pre pracu so subormi nieje a 
zariadil sa uplne inak.

Ale je mi jasne, ze placem na spatnom hrobe.

> Do Pl/pgSQL je 
> lze doplnit, cca po za hodinku programovani si zpristupnite api. Problem 
> je s uvolnovanim descriptoru souboru pri pripadne chybe v procedure, 
> jelikoz PostgreSQL nezna pro custom datove typy destruktor.
> 
> Pavel
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz


From zakkr na zf.jcu.cz  Thu Feb 26 14:52:00 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 26 Feb 2004 14:52:00 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226082605.GA1680@anxur.fi.muni.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz>
Message-ID: <20040226135200.GA9785@zf.jcu.cz>

On Thu, Feb 26, 2004 at 09:26:05AM +0100, Honza Pazdziora wrote:
> On Thu, Feb 26, 2004 at 07:17:44AM +0100, "Zíka Aleš, Ing." wrote:
> > 
> > 	No jasne, sem s tim !!!
> > 	Pred par tydny jsem si tu stezoval, ze mi databaze u providera na
> > webu blbe tridi cestinu a z reakci tak nejak vyplynulo, ze mam nejspis
> > smulu...
> 
> http://www.fi.muni.cz/~adelton/l10n/
> http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string-0.50.tar.gz

 Tak jsem  si dovolil to trosku  ucesat opravit dve chybicky  a poslat o
 tom neco  svou patkovskou anglictinou  do pgsql-hackers :-) Ted  dej se
 vule bozi... Najdete to na:

 ftp://ftp2.zf.jcu.cz/users/zakkr/pg/postgresql-nls-string-0.51.tar.gz

 Jinak dik za pekny napad!

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Thu Feb 26 15:10:31 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Thu, 26 Feb 2004 15:10:31 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226135200.GA9785@zf.jcu.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz> <20040226135200.GA9785@zf.jcu.cz>
Message-ID: <20040226141031.GJ1680@anxur.fi.muni.cz>

On Thu, Feb 26, 2004 at 02:52:00PM +0100, Karel Zak wrote:
> 
>  Tak jsem  si dovolil to trosku  ucesat opravit dve chybicky  a poslat o
>  tom neco  svou patkovskou anglictinou  do pgsql-hackers :-) Ted  dej se
>  vule bozi... Najdete to na:
> 
>  ftp://ftp2.zf.jcu.cz/users/zakkr/pg/postgresql-nls-string-0.51.tar.gz

Diky.

Nejsem si jist, jestli je spravne vracet null v pripade

	VARSIZE(txt) - VARHDRSZ) <= 0

-- prece i prazdny retezec ma narok byti prohnan strxfrm (a neslucovan
s nullem). Pravda, je pak potreba udelat obezlicku a alokovat aspon
jeden bajt, jinak palloc pada.

Pak me jeste napadlo, ze by se vlastne rovnou mohlo alokovat
3 * rest + VARHDRSZ a provest tu sprintf konverzi cyklem odshora, nad
tim samym bufferem.

Hmmm. Uvidime, jaka bude odezva.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From zakkr na zf.jcu.cz  Thu Feb 26 15:37:27 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 26 Feb 2004 15:37:27 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226141031.GJ1680@anxur.fi.muni.cz>
References: <A458B72B045BD811959B0002A562DC41AACC@fupelnt2.pel.br.ds.mfcr.cz> <20040226082605.GA1680@anxur.fi.muni.cz> <20040226135200.GA9785@zf.jcu.cz> <20040226141031.GJ1680@anxur.fi.muni.cz>
Message-ID: <20040226143727.GB9785@zf.jcu.cz>

On Thu, Feb 26, 2004 at 03:10:31PM +0100, Honza Pazdziora wrote:
> On Thu, Feb 26, 2004 at 02:52:00PM +0100, Karel Zak wrote:
> > 
> >  Tak jsem  si dovolil to trosku  ucesat opravit dve chybicky  a poslat o
> >  tom neco  svou patkovskou anglictinou  do pgsql-hackers :-) Ted  dej se
> >  vule bozi... Najdete to na:
> > 
> >  ftp://ftp2.zf.jcu.cz/users/zakkr/pg/postgresql-nls-string-0.51.tar.gz
> 
> Diky.
> 
> Nejsem si jist, jestli je spravne vracet null v pripade
> 
> 	VARSIZE(txt) - VARHDRSZ) <= 0
> 
> -- prece i prazdny retezec ma narok byti prohnan strxfrm (a neslucovan
> s nullem). Pravda, je pak potreba udelat obezlicku a alokovat aspon
> jeden bajt, jinak palloc pada.

 Zitra na to kouknum je pravda, ze NULL != "".

> Pak me jeste napadlo, ze by se vlastne rovnou mohlo alokovat
> 3 * rest + VARHDRSZ a provest tu sprintf konverzi cyklem odshora, nad
> tim samym bufferem.

 Pokud myslis, usetrit volani palloc() tak to je celkem jedno, protoze
 to je hodne lacine volani :-) Ale moznost by to byla, kouknu na to.

 Jeste neco, prozor na "text" jako  datovy typ protoze neobsahuje '\0' a
 volat  funkce (treba  strxfrm)  libc,  ktere predpokladaji  terminovany
 string  je  osemetny  bug. Napriklad  ta  predesla  verze  nls_string()
 vracela  pro stejny  vstup ruzny  vystup  na jehoz  konci byl  rozlicny
 balast z pameti za "txt".

> Hmmm. Uvidime, jaka bude odezva.

 Nejhure zadna  :-) Nebo to nekdo  rozcupuje jako blbost, ale  duvod mne
 nenapada. Snad jen mozny rychlostni  problem se prepinanim locales, ale
 to uz jsem jednou v podobe to_char() do PostgreSQL dostal :-)
 
    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From horak na sitmp.cz  Thu Feb 26 15:38:25 2004
From: horak na sitmp.cz (=?US-ASCII?Q?Horak_Daniel?=)
Date: Thu, 26 Feb 2004 15:38:25 +0100
Subject: PostgreSQL a temporary tabulky a trideni
Message-ID: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz>

> > Hmmm. Uvidime, jaka bude odezva.
> 
>  Nejhure zadna  :-) Nebo to nekdo  rozcupuje jako blbost, ale 
>  duvod mne
>  nenapada. Snad jen mozny rychlostni  problem se prepinanim 
> locales, ale
>  to uz jsem jednou v podobe to_char() do PostgreSQL dostal :-)

Tom Lane uz se ozval a trochu to zdrbnul ;-)


			Dan

From zakkr na zf.jcu.cz  Thu Feb 26 15:48:08 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Thu, 26 Feb 2004 15:48:08 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz>
Message-ID: <20040226144808.GD9785@zf.jcu.cz>

On Thu, Feb 26, 2004 at 03:38:25PM +0100, Horak Daniel wrote:
> > > Hmmm. Uvidime, jaka bude odezva.
> > 
> >  Nejhure zadna  :-) Nebo to nekdo  rozcupuje jako blbost, ale 
> >  duvod mne
> >  nenapada. Snad jen mozny rychlostni  problem se prepinanim 
> > locales, ale
> >  to uz jsem jednou v podobe to_char() do PostgreSQL dostal :-)
> 
> Tom Lane uz se ozval a trochu to zdrbnul ;-)

 Jo, ten clovek nedokaze nikdy prekvapit, ze by na necem neco nenasel...
 :-)

 Pokud by  nekdo udelal rychlostni  testy s tim jak  moc je v  te funkci
 drahe setlocale(), bylo by to fain. Ja jdu domu.

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From stehule na kix.fsv.cvut.cz  Thu Feb 26 15:51:09 2004
From: stehule na kix.fsv.cvut.cz (Pavel Stehule)
Date: Thu, 26 Feb 2004 15:51:09 +0100 (CET)
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226143727.GB9785@zf.jcu.cz>
Message-ID: <Pine.LNX.4.44.0402261550020.32745-100000@kix.fsv.cvut.cz>

> 
> > Hmmm. Uvidime, jaka bude odezva.
> 
>  Nejhure zadna  :-) Nebo to nekdo  rozcupuje jako blbost, ale  duvod mne
>  nenapada. Snad jen mozny rychlostni  problem se prepinanim locales, ale
>  to uz jsem jednou v podobe to_char() do PostgreSQL dostal :-)
>  
>     Karel
> 
 
O mem mimipatchy do pg_dumpu se zacalo mluvit po mesici a pul. Chce to 
cekat a doufat :-)

ps


From zakkr na zf.jcu.cz  Fri Feb 27 11:22:14 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Fri, 27 Feb 2004 11:22:14 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040226144808.GD9785@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz> <20040226144808.GD9785@zf.jcu.cz>
Message-ID: <20040227102214.GA19835@zf.jcu.cz>

On Thu, Feb 26, 2004 at 03:48:08PM +0100, Karel Zak wrote:
>  Pokud by  nekdo udelal rychlostni  testy s tim jak  moc je v  te funkci

        # SELECT count(*) FROM nlstest;
         count
        --------
         100000

        # SELECT data FROM nlstest ORDER BY upper(data) LIMIT 1;
        Time: 1213.87 ms


        # SELECT data FROM nlstest ORDER BY nls_string(data, 'en_US') LIMIT 1;
        Time: 4269.00 ms


 Jeste jsem tam opravil (snad dobre)  to na co narazel Tom Lane. Bohuzel
 ke  koplikaci  je  treba  spi.h  a nejsem  si  jist  maji-li  ho  bezne
 distribucni  balicky.   Pokud  ne  tak  je  treba  mit  nekde  zdrojaky
 PostgreSQL.

    ftp://ftp2.zf.jcu.cz/users/zakkr/pg/

 Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Fri Feb 27 13:23:12 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Fri, 27 Feb 2004 13:23:12 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040227102214.GA19835@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz> <20040226144808.GD9785@zf.jcu.cz> <20040227102214.GA19835@zf.jcu.cz>
Message-ID: <20040227122312.GA18933@anxur.fi.muni.cz>

On Fri, Feb 27, 2004 at 11:22:14AM +0100, Karel Zak wrote:
> On Thu, Feb 26, 2004 at 03:48:08PM +0100, Karel Zak wrote:
> >  Pokud by  nekdo udelal rychlostni  testy s tim jak  moc je v  te funkci
> 
>  Jeste jsem tam opravil (snad dobre)  to na co narazel Tom Lane. Bohuzel

Neni mi uplne jasne, proc to tam musi byt, pokud pred tim elogem ten
setlocale neuspel a navic's tam mel, ze se vraci pro jistotu jeste
zpet. Nejaky odkaz na thread / dokument, ktery by se tim podrobneji
zabyval?

>  ke  koplikaci  je  treba  spi.h  a nejsem  si  jist  maji-li  ho  bezne
>  distribucni  balicky.   Pokud  ne  tak  je  treba  mit  nekde  zdrojaky

Fedora to v -devel ma.

>  PostgreSQL.
> 
>     ftp://ftp2.zf.jcu.cz/users/zakkr/pg/

Na
	http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string/

jsem dal 0.53, kde je

	No setlocale is performed when the standard locale is used.
	The multiplication factor is cached across invocations.
	Removed memsets.
	Fixed error by one on txt_tmp allocation.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From zakkr na zf.jcu.cz  Fri Feb 27 14:12:40 2004
From: zakkr na zf.jcu.cz (Karel Zak)
Date: Fri, 27 Feb 2004 14:12:40 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040227122312.GA18933@anxur.fi.muni.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz> <20040226144808.GD9785@zf.jcu.cz> <20040227102214.GA19835@zf.jcu.cz> <20040227122312.GA18933@anxur.fi.muni.cz>
Message-ID: <20040227131240.GA28395@zf.jcu.cz>

On Fri, Feb 27, 2004 at 01:23:12PM +0100, Honza Pazdziora wrote:
> On Fri, Feb 27, 2004 at 11:22:14AM +0100, Karel Zak wrote:
> > On Thu, Feb 26, 2004 at 03:48:08PM +0100, Karel Zak wrote:
> > >  Pokud by  nekdo udelal rychlostni  testy s tim jak  moc je v  te funkci
> > 
> >  Jeste jsem tam opravil (snad dobre)  to na co narazel Tom Lane. Bohuzel
> 
> Neni mi uplne jasne, proc to tam musi byt, pokud pred tim elogem ten
> setlocale neuspel a navic's tam mel, ze se vraci pro jistotu jeste
> zpet. Nejaky odkaz na thread / dokument, ktery by se tim podrobneji
> zabyval?

 Jde o to, ze elog(ERROR, ...) se nevraci, ale udela siglongjmp() na
 misto kde byl naposledy volan sigsetjmp(). 
 
 A my  v miste kde jsou  nastavene jine locales volame  funkce (palloc),
 ktere  mohou obsahovat  volani  elog(). To by  pak  zamenalo, ze  nikdy
 nedojde k nastaveni puvodnich locale,  ale PostgreSQL se vrati nemam do
 stavu daleko  pred volanim  nls_string(). Proste je pteba  osetrit, aby
 vzdy byl zavolan setlocale() s puvodnim nastavenim.

 Reseni je ulozit si puvodni pozici  pro ten long jump, a nastavit jinou
 pozici,  ktera  zajisti  vraceni  locales  a  nasledne  udela  jump  na
 puvodni. Snad se to z toho co jsem psal da pochopit :-) Jinak viz treba
 zdrojaky PL/TCL.

> 	http://www.fi.muni.cz/~adelton/l10n/postgresql-nls-string/
> 
> jsem dal 0.53, kde je

 Nezkousel jsem, ale pri pohledu na zdrojaky to vypada dobre. Dam to
 take k sobe na FTP pokud by tam nekdo z PostgreSQL listu neco hledal
 (hmm.. asi tam dam README s URL na mini.cz).

    Karel

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

From adelton na informatics.muni.cz  Fri Feb 27 14:29:49 2004
From: adelton na informatics.muni.cz (Honza Pazdziora)
Date: Fri, 27 Feb 2004 14:29:49 +0100
Subject: PostgreSQL a temporary tabulky a trideni
In-Reply-To: <20040227131240.GA28395@zf.jcu.cz>
References: <66EFFC1A2B0A424E87D68EC10B1F458D03DABD@EXCH2.mmp.plzen-city.cz> <20040226144808.GD9785@zf.jcu.cz> <20040227102214.GA19835@zf.jcu.cz> <20040227122312.GA18933@anxur.fi.muni.cz> <20040227131240.GA28395@zf.jcu.cz>
Message-ID: <20040227132949.GC18933@anxur.fi.muni.cz>

On Fri, Feb 27, 2004 at 02:12:40PM +0100, Karel Zak wrote:
>  
>  A my  v miste kde jsou  nastavene jine locales volame  funkce (palloc),
>  ktere  mohou obsahovat  volani  elog(). To by  pak  zamenalo, ze  nikdy

Chapu, palloc je potencialni problem.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.

From qzzt2jkuy na valley.ne.jp  Fri Feb 27 23:43:54 2004
From: qzzt2jkuy na valley.ne.jp (Loyd Khan)
Date: Fri, 27 Feb 04 22:43:54 GMT
Subject: In a rising penny stock arena, this is a low risk situation wtwvo ml zclyp
Message-ID: <mp7$9-zl-uf8x28-$50e8zr72@z9gfnsje.ur>

Wall Street Financial Times Newsletter

Specializing in Undervalued Small Cap Stocks for Immediate Breakout

We have the #1 track record for our picks in 2004:

GETC at .12		Currently .50	High .68 UP 467%
TLPE at 1.12	Currently 3.35	High 4.40 UP 293%
SWYC at .18 	Currently .71	High .81 UP 350%
DNYY at .47	Currently 1.42	High 1.85 UP 294%

Immediate Investor Recommendation
Our Hottest Sales and Earnings Play
Projected to Triple in 7 Days:

Life Energy and Technology Holdings, Inc.
(OTCBB: LETH)

Price--- 1.27
Sales Orders Received '03--- over $150 Million +300% growth vs. '02
Est. Sales Growth '04--- +165%
Results from latest 10-Q:
Total Assets--- 36.8 million vs. 16.8 million
Cash--- 23.4 million vs. deficit
Shareholders Equity--- 12.0 million vs. 2.2 million
Shares Outstanding--- 29 mill
Est. Shares in Float--- 7 mill
Proj. Value Per Share--- 3.25 -- 3.50
Rating--- Urgent Buy

LETH is thriving as an emerging world leader in the conversion of waste 
materials into electrical energy by utilizing their Biosphere Process System, 
making them the hottest undervalued stock at this price level where shares 
are ready to explode on huge investor attention.

Sales have rocketed beyond all estimates for LETH with no signs of 
slowing. The numbers continue to stack-up as sales orders for the Biosphere 
exceed $150 Million over the past year while the stock price doesn't yet 
reflect the appearance of these impressive figures on an upcoming balance 
sheet. We are not the first to uncover this phenomenon as the stock is under 
accumulation, but we are acting aggressively on this recently filed data.

The unique proprietary technology of the Biosphere fills an urgent 
worldwide need for cost-effective renewable energy sources and a 
corresponding universal need to solve critical problems in the disposal of 
waste. The Biosphere System provides the highest level of innovative 
technology while securing worldwide acceptance for a revolutionary product 
designed to significantly impact the global waste problem while 
simultaneously generating electricity. 

The Biosphere System enables LETH to draw revenue from the disposal of 
various types of waste at 5 to 7 tons per hour including such materials as:
Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, 
medical waste, industrial waste, shale oil, sour natural gas, and the huge 
market of used tires are all converted in the Biosphere Process. LETH also
profits from the sale of electricity created from the waste conversion on a 
continuous basis by generating 5 to 10 mega-watts per hour of electricity 
which is then sold to replenish the local or national grid. 

LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a 
leader and one of the largest providers in environmental, mechanical, and 
electrical management consulting services primarily for the US Government 
with annual sales of $800 Million. Tetra Tech will coordinate permitting, 
installation and continuous worldwide monitoring of the Biosphere Process 
System for LETH. Tetra Tech is now in the process of obtaining Department 
of Environmental Quality permitting for the Biosphere Process in the state of 
Louisiana. This is a monumental event for LETH which opens the 
floodgates for major project revenues in Louisiana while having a parallel 
effect on LETH stock in the form of a huge near-term announcement. 

LETH has begun to catch the profit-making attention of investors by 
embracing a major foothold on the global waste problem while a major push 
for generating electricity from alternative sources continues to be the hot 
topic due to shortages and massive power failures. LETH contains all the 
ingredients for major profits as global demand to solve two crisis areas, 
waste and electrical energy, reaches unprecedented levels. We view this 
perfectly timed convergence of events as the catalyst for additional contracts 
that will perpetuate the shattering of the Company's own sales records. We 
are seeing substantial gains for early investors in a ground floor opportunity 
that carries our highest rating for short-term trading profits.

Required LETH information: Certain statements contained in this newsletter 
may be forward looking statements within the meaning of The Private 
Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", 
"may", "will", and "intend" or similar terms may identify these statements. 
We are not a registered investment advisor or a broker dealer. This is not an 
offer to buy or sell securities. No recommendation that the securities of the 
companies profiled should be purchased, sold or held by individuals or 
entities that learn of the profiled companies. This is an independent 
electronic publication that was paid five thousand dollars by an unaffiliated 
third party for the preparation of this company information. Be advised that 
investments in companies profiled are considered to be high-risk and use of 
the content provided is for information purposes only. If anyone decides to 
act as an investor they are advised not to invest without the proper guidance 
from a financial advisor or a registered financial broker. If any party decides 
to participate as an investor then it will be that investor's sole risk. Be 
advised that the purchase of such high-risk securities may result in the loss 
of some or all of the investment. Investors should not rely solely on the 
information presented. Rather, investors should use the information provided 
in this newsletter as a starting point for doing additional independent 
research on the profiled companies in order to allow the investor to form 
their own opinion regarding investing in the profiled companies. Factual 
statements made about the profiled companies are made as of the date stated 
and are subject to change without notice. Investing in micro-cap securities is 
highly speculative and carries an extremely high degree of risk. All 
information provided about the profiled companies may include information 
provided by outside sources, such as research reports, public filings, and 
information provided by management of the profiled company. 

xtcmzq mkdiamuz

From quianaikerd na usclargo.com  Fri Feb 27 21:42:07 2004
From: quianaikerd na usclargo.com (Richard Clark)
Date: Fri, 27 Feb 2004 12:42:07 -0800
Subject: SPEED UP Your DSL, Cable, Satellite or T1 Connection, renegotiable bastion propaganda revet
Message-ID: <VJUAWSLHTNGYCOQZGGEJPCPJ@email.ro >

Are you getting the most out of your Internet Connection?

If you're using a DSL, Cable, Satellite or T1 connection you're NOT getting the most speed out of your connection.

Follow us to faster web surfing - http://www.hidor.com?affil=63


No more ads: http://www.qualinet.biz/outsp/


inadequacy

teahouse ductile floodlight butternut meteoric ireland sixteenth continuant dadaist prague salvatore tunic ttl vain director bandwagon licensor credential vera slang bimetallic clog sib way demitting flatworm fourfold caracas buck demarcate constrictor sob glob ossify usurer rundown crosswort serge lieu cunning 

From portsmouth na fanciable.com  Sat Feb 28 23:25:11 2004
From: portsmouth na fanciable.com (Toes V. Unitarianisms)
Date: Sat, 28 Feb 2004 14:25:11 -0800
Subject: Explore really good Super Viagr8a! :) A proteges penetration piggishness.
Message-ID: <101101c3fe49$b2f86be5$a8dd7d02@fanciable.com>

Hey honey! :)
Ignorance is never out of style. It was in fashion yesterday, it is the rage today and it will set the pace tomorrow.

Cialies (Regalio]s>), at cheap prices.
Msot protals charge $20, we charge $4.95. Quite a difeeecrnfe.

CialiBs <bouncce[is knnown as a Super Viagrra or Weekend ViagrBa 
because its efcefts start sooner and last much lgneor.

Shipped worldwide.

Here you will find it: http://www.medz4cheap.com/cia/?dcent



-----
If you do not wish to be pontonier :-)
Enthusiasm is contagious.  You can start an epidemic.
http://www.medz4cheap.com/off.html
Live your life, do your work, then take your hat.