mssql a firebird
Dariusz Drzemicki
Znam MSSQL, nie znam Firebird i nie wiem co mnie czeka przy przysosowaniu
aplikacji z jednej bazy do drugiej.
DD
wloochacz
tablicowego (ale nie szkodzi, ponieważ można to zrobić inaczej), brak
identity (zamiast tego są generatory), brak szeregu procedure/funkcji
systemowych i jeszcze wiele by się znalazło... (np. nie uświadczysz
takich cudów jak operator cube/rollup)
> Znam MSSQL, nie znam Firebird i nie wiem co mnie czeka przy przysosowaniu
> aplikacji z jednej bazy do drugiej.
To zależy, ale z reguły nie powinno być wiekszych problemów.
---
wloochacz
Dariusz Drzemicki
news:cnsbvq$cp7$1...@nemesis.news.tpi.pl...
>> Jakie są róznice pomiędzy MSSQL2000 a Firebird?
> Inna obsługa triggerów (IMHO w FB znacznie fajniej),
Używam triggerów rekursywnych, czy w FB też są?
> brak typu tablicowego (ale nie szkodzi, ponieważ można to zrobić inaczej),
Nie używam.
> brak identity (zamiast tego są generatory),
a newid() jako default można ustawić?
> brak szeregu procedure/funkcji systemowych i jeszcze wiele by się
> znalazło... (np. nie uświadczysz takich cudów jak operator cube/rollup)
Tego nie znam.
>> Znam MSSQL, nie znam Firebird i nie wiem co mnie czeka przy przysosowaniu
>> aplikacji z jednej bazy do drugiej.
> To zależy, ale z reguły nie powinno być wiekszych problemów.
A czy działa kaskadowy update i delete?
Czy istnieje fraza JOIN w instrukcji select?
Czy są publiczne tablice temporarne (##)?
W jakim języku są żródła FB?
Czy są jakieś joby lub odpowiednik agenta?
Czy są narzędzia administracyjne (odpowiedniki Enterprise Mahager, Query
Analizer, Profiler)?
Czy dobry jest help?
Czy są diagramy zintegrowane z tabelami? Moim zdaniem MSSQL ma to rozwiązane
bardzo dobrze.
DD
wloochacz
>>
>>Inna obsługa triggerów (IMHO w FB znacznie fajniej),
> Używam triggerów rekursywnych, czy w FB też są?
raczej w FB będziesz musiał.
>>brak typu tablicowego (ale nie szkodzi, ponieważ można to zrobić inaczej),
> Nie używam.
>>brak identity (zamiast tego są generatory),
> a newid() jako default można ustawić?
Zazwyczaj robi się to za pomocą triggera before insert np. tak:
CREATE TRIGGER TAB_A_BI FOR TAB_A
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW.A IS NULL) THEN
NEW.A = GEN_ID(GEN_TAB_A_ID, 1);
END
>>brak szeregu procedure/funkcji systemowych i jeszcze wiele by się
>>znalazło... (np. nie uświadczysz takich cudów jak operator cube/rollup)
> Tego nie znam.
To polecam BOL -> akurat ten operator to taki kwiatuszek MS SQL :)
>>>Znam MSSQL, nie znam Firebird i nie wiem co mnie czeka przy przysosowaniu
>>>aplikacji z jednej bazy do drugiej.
>>
>>To zależy, ale z reguły nie powinno być wiekszych problemów.
>
> A czy działa kaskadowy update i delete?
Jasne, IB/FB miał wcześniej kasakadową aktulazację niż MS SQL
> Czy istnieje fraza JOIN w instrukcji select?
A ja Ci się wydaje? Przecież to absolutna podstawa :)
> Czy są publiczne tablice temporarne (##)?
Niestety nie - czasem to bardzo boli, ale zazwyczaj zamiast ##tab
wykorzystuje się procedury, tylko że czasem ##tab są wygodniejsze i szybsze.
> W jakim języku są żródła FB?
Dotychczas C, od wersji 1.5 C++
> Czy są jakieś joby lub odpowiednik agenta?
Nie. Trzeba wykorzystać do tego możliwości OS'a.
> Czy są narzędzia administracyjne (odpowiedniki Enterprise Mahager, Query
> Analizer, Profiler)?
Oczywiście polecam www.ibexpert.com
> Czy dobry jest help?
Tu zdania jest podzielone, help istnieje, ale do BOL to duuuuuużo brakuje...
> Czy są diagramy zintegrowane z tabelami?
Tak i nie; w MS SQL to nie są diagramy zintegrowane z tabelami, tylko
raczej z serwerem. Dla FB są oczywiście narzędzia Case (np. Case Studio
czy pełna wersja IBExperta), ale nie jest to realizowane w ten sam
sposób co w MS SQL.
> Moim zdaniem MSSQL ma to rozwiązane bardzo dobrze.
Zapominasz, że MS SQL już dawno przestał być tylko SZBD; czasem mam
wrażenie, że SZBD jest tylko na dokładkę. Z kolei Firebird jest tylko
SZBD (np. brak narzędzi ETL czy odpowiednika Analisys Services), ale czy
to wada? Zdecydowanie nie.
---
wloochacz
PS. FB nie ma jeszcze jednej (IMHO ważnej i przydatnej) funkcjonalności;
nie można zadać zapytania obejmującego kilka baz danych - w MS SQL to
pestka.
PaSkol
> Zapominasz, że MS SQL już dawno przestał być tylko SZBD; czasem mam
> wrażenie, że SZBD jest tylko na dokładkę.
A można prosić o krótkie rozwinięcie. Nie miałem do tej pory
styczności z MSSQL, a zyskam przy okazji tego wątku jakąś orientację.
Czyli: czym więcej jest MSSQL.
--
PaSkol
---=== Każdy usenetowy chwat z Netykietą za pan brat ===---
---=== http://www.pg.gda.pl/~agatek/netq.html ===---
wloochacz
> styczności z MSSQL, a zyskam przy okazji tego wątku jakąś orientację.
> Czyli: czym więcej jest MSSQL.
http://www.chip.pl/arts/archiwum/kts/ktsar_90335.html
http://www.chip.pl/arts/n/sub/article_115125.html
Strona domowa po naszemu:
http://www.microsoft.com/poland/sql/2005/productinfo/
---
wloochacz
Dariusz Drzemicki
>> Używam triggerów rekursywnych, czy w FB też są?
> Nie i nie tęsknie za nimi.
Nie bardzo rozumiem. Triggery rekursywne zapewniają zadziałanie niezależnie
od tego, czy modyfikacja została dokonana w triggerze, czy poza nim. W dużym
systemie to naprawdę upraszcza zarządzanie regułami biznesowymi.
> Do takich zabaw powinieneś napisać procedurę, raczej w FB będziesz musiał.
Szkoda. Bez tego trzeba będzie redundować triggery.
>>>brak identity (zamiast tego są generatory),
>> a newid() jako default można ustawić?
> Zazwyczaj robi się to za pomocą triggera before insert np. tak:
> CREATE TRIGGER TAB_A_BI FOR TAB_A
> ACTIVE BEFORE INSERT POSITION 0
> AS
> BEGIN
> IF (NEW.A IS NULL) THEN
> NEW.A = GEN_ID(GEN_TAB_A_ID, 1);
> END
Wprawdzie wpisanie newid() do default jest szybsze, ale da się to zamienić.
A czy wogóle jest default?
Co do generatorów, to ich nie używam, natomiast do primarykey wpisuję
newid() czyli GUID. Czy FB ma tę funkcję?
Natomiast widzę z przykładu, że jest trigger BEFORE. MSSQL tego nie ma
(tylko FOR i AFTER), a czasami mi tego brakuje.
>> Czy istnieje fraza JOIN w instrukcji select?
> A ja Ci się wydaje? Przecież to absolutna podstawa :)
Chciałem się upewnić. Czasami zdarza się, że coś, co wydaje się podstawowe,
wcale postawowym nie jest.
>> Czy są publiczne tablice temporarne (##)?
> Niestety nie - czasem to bardzo boli, ale zazwyczaj zamiast ##tab
> wykorzystuje się procedury, tylko że czasem ##tab są wygodniejsze i
> szybsze.
Wykorzystuję je w triggerze, kiedy nazwę takiej tabeli trzeba wrzucić do
procedury exec(). Wtedy zwykła tabela temporarna jest niewidoczna wewnątrz
tej procedury.
> wloochacz
> PS. FB nie ma jeszcze jednej (IMHO ważnej i przydatnej) funkcjonalności;
> nie można zadać zapytania obejmującego kilka baz danych - w MS SQL to
> pestka.
Szkoda. Hurtownię danych instaluję na innym walcu, ze względu na wielkość
backupu i wydajność, jednak pracując na walcu produkcyjnym odwołuję się do
hurtowni.
W MSSQL można zaciągać dane i robić selecty z plików excelowych, dbf i
tekstowych. Czy w FB jest też to możliwe?
DD
wloochacz
http://firebird.sourceforge.net/manual/migration-mssql.html
poza tym polecam www.ibphoenix.com
>>Nie i nie tęsknie za nimi.
> Nie bardzo rozumiem. Triggery rekursywne zapewniają zadziałanie niezależnie
> od tego, czy modyfikacja została dokonana w triggerze, czy poza nim. W dużym
> systemie to naprawdę upraszcza zarządzanie regułami biznesowymi.
Hmmm... być może masz rację (gdybym był złośliwy, tobym napisał że w
dużych systemach logikę zazwyczaj umieszcza się na serwerze aplikacji a
nie w bazie danych :P), ale to tylko znaczy, że do problemu będziez
musiał podejść trochę inaczej - być może bardziej uniwersalnie i lepiej
niż dotychczas :)
>>Do takich zabaw powinieneś napisać procedurę, raczej w FB będziesz musiał.
> Szkoda. Bez tego trzeba będzie redundować triggery.
Nie sądzę, wystarczy, że zmienisz sposób postępowania - nadmiarowość
triggerów jest tu zdecydowanie najgorszym pomysłem... (to tak jak z
rekursywnym triggerem - nigdy na 100% nie wiadomo co się kiedy wykona -
ok, wiem że to wcale nie tak, ale mam takie odczucia - to nie jest
prosty elegancki kod :))
> Wprawdzie wpisanie newid() do default jest szybsze, ale da się to zamienić.
Dokłądnie; nawet da się napisać procedurę, która wygeneruje odpowiedni
kod (generatory, PK, triggery) dla tabel - a wszystko po stronie FB :)
> A czy wogóle jest default?
Tak, oczywiście również na poziomie domen.
> Co do generatorów, to ich nie używam, natomiast do primarykey wpisuję
> newid() czyli GUID. Czy FB ma tę funkcję?
I tak i nie - nie istnieje wśród funkcji wbudowanych w SZBD, ale z
łatwością można ją znaleźć w którymś z UDF'ów (User Definied Functions,
zazwyczaj jest to biblioteka dll zawierająca szereg funkcji dodatkowych
- znam taką co ma. np obsługę plików czy operowanie algorytmem MD5 -
GUID to pestka :)). Wystarczy poszukać...
Poza tym jaki jest faktycznie sens stosowania GUID (poza swoistą modą) w
systemie nie-otwartym-na świat? Zajmuje to więcej miejsca niż integer, a
newid() jest równie dobrze unikalny. No chyba, że faktycznie każdy
wiersz musi byuć unikalny w większej skali niż jedna baza danych.
> Natomiast widzę z przykładu, że jest trigger BEFORE. MSSQL tego nie ma
> (tylko FOR i AFTER), a czasami mi tego brakuje.
eee nie widzę tu wielkiej róznicy, poza inną deklaracją triggera.
Dokładnie ten sam efekt przecież można uzyskać w MS SQL wykorzystując
trigery FOR - ale faktyczie w FB jest jakoś fajniej.
> Szkoda. Hurtownię danych instaluję na innym walcu, ze względu na wielkość
> backupu i wydajność, jednak pracując na walcu produkcyjnym odwołuję się do
> hurtowni.
>
> W MSSQL można zaciągać dane i robić selecty z plików excelowych, dbf i
> tekstowych. Czy w FB jest też to możliwe?
Jak powiedziałem w FB nie ma funkcjonaoności systemów ETL (Extract,
Transform and Load czyli wg nomenklatury MS będzie jest to DTS).
Czy szkoda? Czasem może tak, ale nie zapominaj że FB jest za free i za
tę kasę oferuje wcale wydajny i nieźle wyposażony silnik.
---
wloochacz
Dariusz Drzemicki
>>>Nie i nie tęsknie za nimi.
>> Nie bardzo rozumiem. Triggery rekursywne zapewniają zadziałanie
>> niezależnie od tego, czy modyfikacja została dokonana w triggerze, czy
>> poza nim. W dużym systemie to naprawdę upraszcza zarządzanie regułami
>> biznesowymi.
> Hmmm... być może masz rację (gdybym był złośliwy, tobym napisał że w
> dużych systemach logikę zazwyczaj umieszcza się na serwerze aplikacji a
> nie w bazie danych :P),
Tak też zrobiłem na początku, korzystając z rad podręcznikowych, ale
wycofałem się pod wpływem negatywnych doświadczeń.
Na serwerze aplikacji raguły biznesowe są realizowane na obiektach dataset
które są:
- 100 razy wolniejsze w porównaniu z triggerem, (to taki przybliżony wynik),
- niestabilne (najerzone eventami, ciężkie, przy modyfikacji danych nie
można odłączyć disablecontrols, bo rozwala się konstrukcja master-detail),
- jeżeli reguła siedzi w bazie, to będzie działała przy wykorzystaniu innych
kanałów łączności poza serwerm aplikacji (np. cennik dla klienów, który
zamawia towar nie wykorzystuje serwera aplikacji, ale łączy się z bazą i
generuje zamówienie, które wykorzystuje reguły biznesowe).
Dopóki trzymałem reguły na serwerze aplikacji miałem ciągłe problemy ze
stabilnością oraz szybkością działania. Problemy wielce się zmniejszyły, jak
przeniosłem je do bazy.
> ale to tylko znaczy, że do problemu będziez musiał podejść trochę
> inaczej - być może bardziej uniwersalnie i lepiej niż dotychczas :)
>>>Do takich zabaw powinieneś napisać procedurę, raczej w FB będziesz
>>>musiał.
>> Szkoda. Bez tego trzeba będzie redundować triggery.
> Nie sądzę, wystarczy, że zmienisz sposób postępowania - nadmiarowość
> triggerów jest tu zdecydowanie najgorszym pomysłem... (to tak jak z
> rekursywnym triggerem - nigdy na 100% nie wiadomo co się kiedy wykona -
> ok, wiem że to wcale nie tak, ale mam takie odczucia - to nie jest prosty
> elegancki kod :))
Więc jak rozwiążesz taki proste zadanie?
są 2 reguły:
cena=cena katalogowa*(100-rabat%)/100
oraz
VAT=ilość*cena*stawkaVAT%/100
Jak zapewnić wyliczenie VAT przy zmianie rabatu?
Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta z
kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
triggera, który uaktualni VAT.
Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć się o
uaktulanienie VAT.
Chętnie wysłucham bardziej eleganckiego sposobu.
> Poza tym jaki jest faktycznie sens stosowania GUID (poza swoistą modą) w
> systemie nie-otwartym-na świat?
Aby rekord miał unikalny primarykey nie tylko w zakresie tabeli. Można
przenieść taki rekord do hurtowni bez ryzyka, że zderzy się z innym rekordem
z innej tabeli o tym samym primarykey.
Ponadto primarykey jest stringowy, co można wykorzystać do łączenia kluczy.
Z primarykey numerycznym sytuacja się komplikuje.
>Zajmuje to więcej miejsca niż integer,
Nie zauważyłem spadku wydajności, kiedy zacząłem stosować primarykey
varchar(36).
>a newid() jest równie dobrze unikalny. No chyba, że faktycznie każdy wiersz
>musi byuć unikalny w większej skali niż jedna baza danych.
Właśnie tak jest w hurtowni.
>> Natomiast widzę z przykładu, że jest trigger BEFORE. MSSQL tego nie ma
>> (tylko FOR i AFTER), a czasami mi tego brakuje.
> eee nie widzę tu wielkiej róznicy, poza inną deklaracją triggera.
> Dokładnie ten sam efekt przecież można uzyskać w MS SQL wykorzystując
> trigery FOR - ale faktyczie w FB jest jakoś fajniej.
To chyba nie rozumiem. Sądziłem, że BEFORE znaczy przed modyfikacją. W MSSQL
FOR jest już po modyfikacji. Wnioskuję tak, ponieważ nie mogę w takim
triggerze obsłużyć defaulta, jeżeli pole jest not nullable, ani znullować
foreignkey tabeli połączonej relacją z tabelą w której jest usuwawany
rekord.
>> W MSSQL można zaciągać dane i robić selecty z plików excelowych, dbf i
>> tekstowych. Czy w FB jest też to możliwe?
> Jak powiedziałem w FB nie ma funkcjonaoności systemów ETL (Extract,
> Transform and Load czyli wg nomenklatury MS będzie jest to DTS).
> Czy szkoda? Czasem może tak, ale nie zapominaj że FB jest za free i za tę
> kasę oferuje wcale wydajny i nieźle wyposażony silnik.
Wiem, że za free. Nie oczekuję, aby był taki, jak MSSQL, chciałem się tylko
rozeznać, czy możliwości są wystarczające.
Z drugiej strony MSDE do 5 użytkowników też jest za free, a jest to
praktycznie pełny MSSQL.
DD
Moskw@
> Użytkownik "wloochacz" <n...@spam.no> napisał w wiadomości
> news:cnsrhe$d43$1...@nemesis.news.tpi.pl...
>
<ciach>
>>
>>Nie sądzę, wystarczy, że zmienisz sposób postępowania - nadmiarowość
>>triggerów jest tu zdecydowanie najgorszym pomysłem... (to tak jak z
>>rekursywnym triggerem - nigdy na 100% nie wiadomo co się kiedy wykona -
>>ok, wiem że to wcale nie tak, ale mam takie odczucia - to nie jest prosty
>>elegancki kod :))
>
>
> Więc jak rozwiążesz taki proste zadanie?
> są 2 reguły:
> cena=cena katalogowa*(100-rabat%)/100
> oraz
> VAT=ilość*cena*stawkaVAT%/100
>
> Jak zapewnić wyliczenie VAT przy zmianie rabatu?
> Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta z
> kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
> triggera, który uaktualni VAT.
> Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć się o
> uaktulanienie VAT.
> Chętnie wysłucham bardziej eleganckiego sposobu.
>
jestem ciekaw po co takie informacje trzymac w bazie ?? Przeciez to sa
pola wyliczeniowe i trzymanie ich w bazie jest wedlug mnie marnowaniem
miejsca :-( Przeciez to mozna elegancko obsluzyc zapytaniem i/lub po
stronie klienta wyliczajac takie elementy "w locie".
pozdrowienia
Moskw@
Dariusz Drzemicki
news:cnt4qq$453$1...@news.onet.pl...
1. To był przykład na triggery rekursywne, a nie konkretna implementacja.
2. VAT na fakturach zakupu może się różnić od wyliczonego (nieszczęsne
zaokrąglenia), więc kalkulacja tego nie zapewni. Pole musi być.
3. Cena dla klienta i rabat to wzajemne zależności i obie muszą być
edytowalne, a wiadomo, że cena musi być określona do 1 gr, a edycja rabatu
może nie dać każdej ceny.
4. Wartości istotne takie jak VAT powinny być łatwo dostępne, a nie
wyliczane za każdym razem. Wykorzystuje się je do wielu celów (w rejestrach
VAT, innych zestawieniach, kostkach decyzyjnych), więc konieczność tworzenia
skomplikowanych wyrażeń do uzyskania często potrzebnych wartości jest
uciążliwe i narażone na błędy. Znacznie prościej jest posłużyć się
triggerem, który działa niezawodnie.
DD
Dariusz Drzemicki
> news:cnt4qq$453$1...@news.onet.pl...
>> pola wyliczeniowe i trzymanie ich w bazie jest wedlug mnie marnowaniem
>> miejsca :-( Przeciez to mozna elegancko obsluzyc zapytaniem i/lub po
>> stronie klienta wyliczajac takie elementy "w locie".
>> pozdrowienia
>> Moskw@
>
> 1. To był przykład na triggery rekursywne, a nie konkretna implementacja.
> 2. VAT na fakturach zakupu może się różnić od wyliczonego (nieszczęsne
> zaokrąglenia), więc kalkulacja tego nie zapewni. Pole musi być.
> 3. Cena dla klienta i rabat to wzajemne zależności i obie muszą być
> edytowalne, a wiadomo, że cena musi być określona do 1 gr, a edycja rabatu
> może nie dać każdej ceny.
> 4. Wartości istotne takie jak VAT powinny być łatwo dostępne, a nie
> wyliczane za każdym razem. Wykorzystuje się je do wielu celów (w
> rejestrach VAT, innych zestawieniach, kostkach decyzyjnych), więc
> konieczność tworzenia skomplikowanych wyrażeń do uzyskania często
> potrzebnych wartości jest uciążliwe i narażone na błędy. Znacznie prościej
> jest posłużyć się triggerem, który działa niezawodnie.
a ponadto jak posortujesz po polu wyliczeniowym?
DD
Paweł Świerzko
>
> > Więc jak rozwiążesz taki proste zadanie?
> > są 2 reguły:
> > cena=cena katalogowa*(100-rabat%)/100
> > oraz
> > VAT=ilość*cena*stawkaVAT%/100
> >
> > Jak zapewnić wyliczenie VAT przy zmianie rabatu?
> > Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta
z
> > kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
> > triggera, który uaktualni VAT.
> > Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć
się o
> > uaktulanienie VAT.
> > Chętnie wysłucham bardziej eleganckiego sposobu.
> >
wyliczalnego ? :
create table
vat coputedby(ilosc * cena * stawkavat%/100)
I obędzie się bez triggerów. Każda zmiana ceny spowodowana zmianą rabatu
powoduje przeliczenie vatu.
(przynajmniej ja tak robię - może popełniam błąd, napiszcie co o tym
sądzicie)
Paweł
wloochacz
> a ponadto jak posortujesz po polu wyliczeniowym?
w MS SQL będzie to:
select itemnmbr, dex_row_id/100 as calc_field
from iv00101 order by calc_field
a w MS SQL i FB zadziała tak:
select itemnmbr, dex_row_id/100 as calc_field
from iv00101 order by 2
Poza tym zawsze można widok zrobić ;-)
---
wloochacz
PS. na resztę też odpowiem, tylko się kawy napiję...
Dariusz Drzemicki
wiadomości news:cnun9a$s0k$1...@news.onet.pl...
>> > Więc jak rozwiążesz taki proste zadanie?
>> > są 2 reguły:
>> > cena=cena katalogowa*(100-rabat%)/100
>> > oraz
>> > VAT=ilość*cena*stawkaVAT%/100
>> >
>> > Jak zapewnić wyliczenie VAT przy zmianie rabatu?
>> > Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta
> z
>> > kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
>> > triggera, który uaktualni VAT.
>> > Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć
> się o
>> > uaktulanienie VAT.
>> > Chętnie wysłucham bardziej eleganckiego sposobu.
>> >
> A czy dla pola przechowującego vat nie można zdefiniować zwykłego pola
> wyliczalnego ? :
> create table
> vat coputedby(ilosc * cena * stawkavat%/100)
> I obędzie się bez triggerów. Każda zmiana ceny spowodowana zmianą rabatu
> powoduje przeliczenie vatu.
> (przynajmniej ja tak robię - może popełniam błąd, napiszcie co o tym
> sądzicie)
Instrukcja ciekawa, w MSSQL jej nie znalazłem.
Tylko, czy pole jest readonly? Czasami zdarza się, że VAT trzeba poprawić ze
względu na zaokrąglenia (w fakturach zakupu).
DD
Dariusz Drzemicki
> [ciach]
>> a ponadto jak posortujesz po polu wyliczeniowym?
> Jak to jak? Zwyczajnie:
> w MS SQL będzie to:
> select itemnmbr, dex_row_id/100 as calc_field
> from iv00101 order by calc_field
>
> a w MS SQL i FB zadziała tak:
> select itemnmbr, dex_row_id/100 as calc_field
> from iv00101 order by 2
>
> Poza tym zawsze można widok zrobić ;-)
Masz rację. Tu jest siła SQL.
Miałem na myśli pole kalkulacyjne na kliencie, ale rzeczywiście przerzucając
kalkulację na sql można to rozwiązać. Na kliencie będzie to już pole fkData.
Zostanie tylko mała niedogodność mianowicie nie zobaczymy wartości tego pola
podczas edycji dopóki nie zapiszemy danych na sewerze.
DD
wloochacz
> wycofałem się pod wpływem negatywnych doświadczeń.
> Na serwerze aplikacji raguły biznesowe są realizowane na obiektach dataset
> które są:
> - 100 razy wolniejsze w porównaniu z triggerem, (to taki przybliżony wynik),
o szybkość chodzi. Poza tym, to zależy co było tym serwerm i w jakiej
technologii został zrealizowany serwer aplikacji? Stawiam na DCOM bez
MTS'a - zgadłem?
> - niestabilne (najerzone eventami, ciężkie, przy modyfikacji danych nie
> można odłączyć disablecontrols, bo rozwala się konstrukcja master-detail),
Jakich komponentów używasz? Z zerwanie master-detail to chyba lekka
przesada - nie są znane mi takiem przypadki (ale i nie programuje za
pomocą wszystkich kompoinentów dostępnych w Delphi).
Aaa.... przypomniało mi się - tylko nie mów, że używasz do wiązania
master-detail mechanizmu wbudowanego w TTable?
> - jeżeli reguła siedzi w bazie, to będzie działała przy wykorzystaniu innych
> kanałów łączności poza serwerm aplikacji (np. cennik dla klienów, który
> zamawia towar nie wykorzystuje serwera aplikacji, ale łączy się z bazą i
> generuje zamówienie, które wykorzystuje reguły biznesowe).
Fajnie - a podobno dokładnie w tym celu wymyślono appsrv i używa się
WebService'ów do wymiany danych - tylko nie zawsze warto, także
proponuję zostawić ten temat.
>>Nie sądzę, wystarczy, że zmienisz sposób postępowania - nadmiarowość
>>triggerów jest tu zdecydowanie najgorszym pomysłem... (to tak jak z
>>rekursywnym triggerem - nigdy na 100% nie wiadomo co się kiedy wykona -
>>ok, wiem że to wcale nie tak, ale mam takie odczucia - to nie jest prosty
>>elegancki kod :))
>
> Więc jak rozwiążesz taki proste zadanie?
> są 2 reguły:
> cena=cena katalogowa*(100-rabat%)/100
> oraz
> VAT=ilość*cena*stawkaVAT%/100
>
> Jak zapewnić wyliczenie VAT przy zmianie rabatu?
> Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta z
> kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
> triggera, który uaktualni VAT.
> Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć się o
> uaktulanienie VAT.
OK, ale w czym problem? Do tego jest potrzebny rekursywny trigger?
Przecież to wszystko można napisać w ciele jednego triggera lub jednej
procedury (tylko, że wtedy VAT będzie przeliczany zawsze). Co tak
naprawdę daje Ci rekursywny trigger? Tylko to że nie muszisz
niepotrzebnie odpalać kodu VAT?
Jak rozumiem w tym triggerze masz coś na kształ:
IF update(rabat)
policz_rabat
ELSE
policz_VAT
gdzie policz_rabat liczy i wywoluje ponownie ten sam trigger aby
polkiczyc VAT? Skoro tak, to rozbij to na osobne procedury, pierwsza
będzie lliczyć cenę i odpalać procedurę która policzy VAT, druga tylko
policzy VAT.
>>Poza tym jaki jest faktycznie sens stosowania GUID (poza swoistą modą) w
>>systemie nie-otwartym-na świat?
> Aby rekord miał unikalny primarykey nie tylko w zakresie tabeli. Można
> przenieść taki rekord do hurtowni bez ryzyka, że zderzy się z innym rekordem
> z innej tabeli o tym samym primarykey.
> Ponadto primarykey jest stringowy, co można wykorzystać do łączenia kluczy.
Napisałeś, że to GUID, a to nie jest string! I właśnie, nie można GUID'ó
łączyć - jedynymi dozwolonymi operatorami są opertatory porównania oraz
is null.
> Z primarykey numerycznym sytuacja się komplikuje.
fakt
>>Zajmuje to więcej miejsca niż integer,
> Nie zauważyłem spadku wydajności, kiedy zacząłem stosować primarykey
> varchar(36).
I jeszcze varchar? Powiedziałbym, że niemożliwe...
>>>Natomiast widzę z przykładu, że jest trigger BEFORE. MSSQL tego nie ma
>>>(tylko FOR i AFTER), a czasami mi tego brakuje.
>>
>>eee nie widzę tu wielkiej róznicy, poza inną deklaracją triggera.
>>Dokładnie ten sam efekt przecież można uzyskać w MS SQL wykorzystując
>>trigery FOR - ale faktyczie w FB jest jakoś fajniej.
>
> To chyba nie rozumiem. Sądziłem, że BEFORE znaczy przed modyfikacją. W MSSQL
> FOR jest już po modyfikacji. Wnioskuję tak, ponieważ nie mogę w takim
> triggerze obsłużyć defaulta, jeżeli pole jest not nullable, ani znullować
> foreignkey tabeli połączonej relacją z tabelą w której jest usuwawany
> rekord.
ups - pomyłka; chodzi mi o triggery INSTEAD OF
>>>W MSSQL można zaciągać dane i robić selecty z plików excelowych, dbf i
>>>tekstowych. Czy w FB jest też to możliwe?
>>
>>Jak powiedziałem w FB nie ma funkcjonaoności systemów ETL (Extract,
>>Transform and Load czyli wg nomenklatury MS będzie jest to DTS).
>>Czy szkoda? Czasem może tak, ale nie zapominaj że FB jest za free i za tę
>>kasę oferuje wcale wydajny i nieźle wyposażony silnik.
>
> Wiem, że za free. Nie oczekuję, aby był taki, jak MSSQL, chciałem się tylko
> rozeznać, czy możliwości są wystarczające.
> Z drugiej strony MSDE do 5 użytkowników też jest za free, a jest to
> praktycznie pełny MSSQL.
No tu to pojechałeś - pełny? Nie ma OLAP'a, DTS'a a to ograniczenie do
25 równoległych zapytań (nie użytkowników/sesji i nie pomyliłem się - MS
zmienił ograniczenia MSDE) i baza danych do 2 giga to jakaś absolutna
porażka. Poza tym wspiera prawie cały T-SQL, więc dla Ciebie na pewno
jest to naturalny wybór.
Oczywiście jest jeszcze SQL Server 2005 Express Edition (beta 2), a ten
zdecydowanie atrakcyjnie się prezentuje na tle MSDE.
---
wloochacz
wloochacz
> Miałem na myśli pole kalkulacyjne na kliencie, ale rzeczywiście przerzucając
> kalkulację na sql można to rozwiązać. Na kliencie będzie to już pole fkData.
> Zostanie tylko mała niedogodność mianowicie nie zobaczymy wartości tego pola
> podczas edycji dopóki nie zapiszemy danych na sewerze.
Dlatego pola kalkulowane serwera, nalezy zastąpić polami klakulowanymi
klienta - o ile to oczywiście możliwe i potrzebne.
---
wloochacz
wloochacz
[ilosc] money,
[cena] money,
[stawkavat] money,
[VAT] AS ([ilosc] * [cena] * ([stawkavat%]/100))
)
> Tylko, czy pole jest readonly?
> Czasami zdarza się, że VAT trzeba poprawić ze
> względu na zaokrąglenia (w fakturach zakupu).
I dlatego pole klakulowane tu się średnio nadaje...
---
wloochacz
Dariusz Drzemicki
>> Tak też zrobiłem na początku, korzystając z rad podręcznikowych, ale
>> wycofałem się pod wpływem negatywnych doświadczeń.
>> Na serwerze aplikacji raguły biznesowe są realizowane na obiektach
>> dataset które są:
>> - 100 razy wolniejsze w porównaniu z triggerem, (to taki przybliżony
>> wynik),
> Fakt - są wolniejsze, ale w zastosowaniu osobnej warstwy dla logiki nie o
> szybkość chodzi.
Jak to nie. Szybkość i stabilność to kryterium wstępne aplikacji.
>Poza tym, to zależy co było tym serwerm i w jakiej technologii został
>zrealizowany serwer aplikacji? Stawiam na DCOM bez MTS'a - zgadłem?
Tak. Ale sądzę, że nie tylko chodzi o komunikację. DataSet jest niewydajny.
>> - niestabilne (najerzone eventami, ciężkie, przy modyfikacji danych nie
>> można odłączyć disablecontrols, bo rozwala się konstrukcja
>> master-detail),
> Jakich komponentów używasz?
ADODataSet
> Z zerwanie master-detail to chyba lekka przesada - nie są znane mi takiem
> przypadki (ale i nie programuje za pomocą wszystkich kompoinentów
> dostępnych w Delphi).
Master z detailem jest połaczony poprzez DataSource. Disablecontrols wyłącza
DataSource.
> Aaa.... przypomniało mi się - tylko nie mów, że używasz do wiązania
> master-detail mechanizmu wbudowanego w TTable?
Nie używam TTable, tylko wiązania DataSource.dataset:=MasterDataset,
DetailDataSet.DataSource:=DataSource.
>> - jeżeli reguła siedzi w bazie, to będzie działała przy wykorzystaniu
>> innych kanałów łączności poza serwerm aplikacji (np. cennik dla klienów,
>> który zamawia towar nie wykorzystuje serwera aplikacji, ale łączy się z
>> bazą i generuje zamówienie, które wykorzystuje reguły biznesowe).
> Fajnie - a podobno dokładnie w tym celu wymyślono appsrv i używa się
> WebService'ów do wymiany danych - tylko nie zawsze warto, także proponuję
> zostawić ten temat.
Ale po co? Rosną koszty, administracja. Czy skórka warta wyprawki? Mój
target, to klienci samoobługowi, którzy nie mają administratora.
>> Więc jak rozwiążesz taki proste zadanie?
>> są 2 reguły:
>> cena=cena katalogowa*(100-rabat%)/100
>> oraz
>> VAT=ilość*cena*stawkaVAT%/100
>>
>> Jak zapewnić wyliczenie VAT przy zmianie rabatu?
>> Robię to poprzez 2 triggery rekursywne. Zmiana rabatu zmieni cenę, a ta z
>> kolei zmiana, która dokona się w triggerze spowoduje wywołanie drugiego
>> triggera, który uaktualni VAT.
>> Brak rekursywności wymaga, abym przy zmianie rabatu musiał zatroszczyć
>> się o uaktulanienie VAT.
> OK, ale w czym problem? Do tego jest potrzebny rekursywny trigger?
> Przecież to wszystko można napisać w ciele jednego triggera lub jednej
> procedury (tylko, że wtedy VAT będzie przeliczany zawsze). Co tak naprawdę
> daje Ci rekursywny trigger?
Kaskadę triggerów. System jest siecią zależności. W triggerze koncentruję
się na kawałku, czyli zależności jednego pola od zmiany innego lub paru
innych i to wszystko ma działać w złożonej sieci powiązań. Tworząc regułę
zależności pomiędzy rabaten a ceną nie chcę analizować wpływu tych zmian na
inne pola, bo to załatwiają inne triggery.
> Tylko to że nie muszisz niepotrzebnie odpalać kodu VAT?
> Jak rozumiem w tym triggerze masz coś na kształ:
> IF update(rabat)
> policz_rabat
> ELSE
> policz_VAT
Nie. Mam oddzielne wątki:
1. if update(RABAT) ...
2. if update(ILOSC) or update(CENA)...
Rekursywność załatwi mi, że przy zmianie RABATU trigger wywoła się 2
razy,raz przy zmianie rabatu, drugi raz przy zmianie ceny, którą
spowowdowała zmiana rabatu.
> gdzie policz_rabat liczy i wywoluje ponownie ten sam trigger aby polkiczyc
> VAT? Skoro tak, to rozbij to na osobne procedury, pierwsza będzie lliczyć
> cenę i odpalać procedurę która policzy VAT, druga tylko policzy VAT.
Ale ja nie chcę analizować VATu przy zmianie rabatu, bo nie ma
bezpośredniego związku. Zmiana rabatu wpływa na cenę, natomiast zmiana ceny
wpływa na VAT.
>>>Poza tym jaki jest faktycznie sens stosowania GUID (poza swoistą modą) w
>>>systemie nie-otwartym-na świat?
>> Aby rekord miał unikalny primarykey nie tylko w zakresie tabeli. Można
>> przenieść taki rekord do hurtowni bez ryzyka, że zderzy się z innym
>> rekordem z innej tabeli o tym samym primarykey.
>> Ponadto primarykey jest stringowy, co można wykorzystać do łączenia
>> kluczy.
> Napisałeś, że to GUID, a to nie jest string! I właśnie, nie można GUID'ó
> łączyć - jedynymi dozwolonymi operatorami są opertatory porównania oraz is
> null.
Miałem na myśli guid w postaci stringu np:
'06D0D356-F592-4570-BE35-EE407936CFEE'. Taki format zwraca newid().
>> Z primarykey numerycznym sytuacja się komplikuje.
> fakt
>>>Zajmuje to więcej miejsca niż integer,
>> Nie zauważyłem spadku wydajności, kiedy zacząłem stosować primarykey
>> varchar(36).
> I jeszcze varchar? Powiedziałbym, że niemożliwe...
Co jest niemożliwe?
>> Wiem, że za free. Nie oczekuję, aby był taki, jak MSSQL, chciałem się
>> tylko rozeznać, czy możliwości są wystarczające.
>> Z drugiej strony MSDE do 5 użytkowników też jest za free, a jest to
>> praktycznie pełny MSSQL.
> No tu to pojechałeś - pełny?
To taki skrót myślowy. Realizuje wszystkie potrzeby, o które pytałem.
>Nie ma OLAP'a, DTS'a a to ograniczenie do 25 równoległych zapytań (nie
>użytkowników/sesji i nie pomyliłem się - MS zmienił ograniczenia MSDE) i
>baza danych do 2 giga to jakaś absolutna porażka. Poza tym wspiera prawie
>cały T-SQL, więc dla Ciebie na pewno jest to naturalny wybór.
Zgadza się. MSDE jest dla kilentów małych, gdzie koszty serwera są znaczące.
Ale oni nie mają takich potrzeb jak baza powyżej 2GB czy 25 jednoczesnych
zapytań.
> Oczywiście jest jeszcze SQL Server 2005 Express Edition (beta 2), a ten
> zdecydowanie atrakcyjnie się prezentuje na tle MSDE.
Słyszałem, ale jeszcze nie testowałem.
A w czym góruje nad MSDE?
DD
Dariusz Drzemicki
>> Zostanie tylko mała niedogodność mianowicie nie zobaczymy wartości tego
>> pola podczas edycji dopóki nie zapiszemy danych na sewerze.
> Dlatego pola kalkulowane serwera, nalezy zastąpić polami klakulowanymi
> klienta - o ile to oczywiście możliwe i potrzebne.
Więc wrócimy do problemu braku sortowania.
Okazuje się, żeby obsłużyć zarówno sortowanie jak i wyliczanie potrzebne
jest prawdziwe pole a nie kalkulacyjne.
DD
Paweł Świerzko
Użytkownik "Dariusz Drzemicki" <d...@asoft.com.pl> napisał w wiadomości
news:cnus1u$bv9$1...@nemesis.news.tpi.pl...
czy przechowywana w bazie, bo na cholerę mi wpisywać wartość, skoro za
chwilę
przy zmianie jakiegoś parametru na podstawie którego jest wyliczana i tak
zostanie zmieniona,
chyba że w mssql wpisanie wartości "z palucha" blokuje mechanizm wyliczenia
wartości,
ale wtedy w fb proponowałbym dwa pola:
vat_real double precision,
vat_coputed computedby(ilosc * cena * stawkavat%/100)
zaś w zapytaniach o vat
posiłkować się odwołaniem select coalesce(vat_real, vat_computed) vat
da to watość vat jeżeli jest wpisana w vat_real a jeżeli jest null to zwróci
wartość vat_computed
I trigger znikł a pola computed (o ile dobrze pamiętam) i tak nie są
przechowywane w bazie...
Pozdrawiam
Paweł
wloochacz
>>>pola podczas edycji dopóki nie zapiszemy danych na sewerze.
>>
>>Dlatego pola kalkulowane serwera, nalezy zastąpić polami klakulowanymi
>>klienta - o ile to oczywiście możliwe i potrzebne.
>
> Więc wrócimy do problemu braku sortowania.
> Okazuje się, żeby obsłużyć zarówno sortowanie jak i wyliczanie potrzebne
> jest prawdziwe pole a nie kalkulacyjne.
----
wloochacz
Dariusz Drzemicki
>> Instrukcja ciekawa, w MSSQL jej nie znalazłem.
>> Tylko, czy pole jest readonly? Czasami zdarza się, że VAT trzeba poprawić
> ze
>> względu na zaokrąglenia (w fakturach zakupu).
> No to w takim przypadku trzeba się zdecydować, czy wartość jest wyliczana
> czy przechowywana w bazie, bo na cholerę mi wpisywać wartość, skoro za
> chwilę
> przy zmianie jakiegoś parametru na podstawie którego jest wyliczana i tak
> zostanie zmieniona,
Decyzja jest taka, że się wylicza, ale czasami trzeba ją poprawić.
> chyba że w mssql wpisanie wartości "z palucha" blokuje mechanizm
> wyliczenia
> wartości,
> ale wtedy w fb proponowałbym dwa pola:
>
> vat_real double precision,
> vat_coputed computedby(ilosc * cena * stawkavat%/100)
Wystarczy jedno pole, które wylicza się w następstwie triggera update(IL)
lub update(CENA). Natomiast wpis do VAT niczego nie przelicza.
> zaś w zapytaniach o vat
> posiłkować się odwołaniem select coalesce(vat_real, vat_computed) vat
> da to watość vat jeżeli jest wpisana w vat_real a jeżeli jest null to
> zwróci
> wartość vat_computed
To komplikacja, bo ten select ściągam na clientdataset i trzeba oprogramować
dodatkowo obsługę edycji pola VAT.
> I trigger znikł a pola computed (o ile dobrze pamiętam) i tak nie są
> przechowywane w bazie...
Ale pojawiają się problemy implementacyjne, a istnienie triggera mi nie
przeszkadza.
DD
szaman
uruchamianych kaskadowo.
Ale jak widzę się rozwinął i co gorsze wszyscy są w błędzie - mam w
każdym bądź razie takie wrażenie, że nikt tu z dyskutujących nie
orientuje się w problemie.
Mam na myśli sposób liczenia VAT na dokumentach typu FV.
Taka wartości vat, o której dyskutujecie, obliczana dla pojedyńczej
pozycji dokumentu w dowolny sposób, czyli: polem "kalkulowanym" czy
triggerem czy jeszcze inaczej, może mieć zastosowanie jedynie
pomocnicze, np: w rachunkowści ale zarządczej lub innych wynalazkach
jak te kostki decyzyjne, ale napewno nie do rejestrów VAT!
A to, dlatego, że suma zaokrągleń składników nie musi dać takiego
samego wyniku jak zakrąglenie sumy tychże składników.
Vat, szanowni Panowie liczy się inaczej.
Wpierw się grupuje dokumenty według stawki VAT potem sumuje w tych
grupach i dopiero z tych sum wylicza się VAT. Natomiast VAT dla
poszczególnych pozycji FV można wyliczać jak ktoś chce ale tylko w
innych celach tzn. nie na potrzeby księgowości.
To tylko taka moja mała uwaga, mam świadomośc, że odbiega mocno od
triggerów - mam jednak nadzieję że konstruktywna.
Andrzej
Rzeczywiście triggery nie mają nic do rzeczy.
Jednak twój pogląd na liczenie VAT nie do końca jest słuszny. Uwaga
filozoficzna: są rzeczy, o których się nie dyskutuje, w polskiej
przestrzeni kulturowej to koń - jaki jest każdy widzi; także podatek VAT
jest jaki jest, czyli określony przez prawo. Głupie czy nie - trzeba go
przestrzegać. A co mówi prawo o naliczaniu VAT na fakturze:
"ROZPORZĄDZENIE MINISTRA FINANSÓW Z DNIA 22 MARCA 2002R.
W SPRAWIE WYKONANIA NIEKTÓRYCH PRZEPISÓW USTAWY O PODATKU OD TOWARÓW I
USŁUG ORAZ PODATKU AKCYZOWYM
PAR. 35
PKT 2. SPRZEDAWCA MOŻE OKREŚLIĆ NA FAKTURZE RÓWNIEŻ KWOTY PODATKU
DOTYCZĄCE WARTOŚCI SPRZEDAŻY POSZCZEGÓLNYCH TOWARÓW I USŁUG WYKAZANYCH W
TEJ FAKTURZE; W TYM PRZYPADKU ŁĄCZNA KWOTA PODATKU MOŻE BYĆ USTALONA W
WYNIKU PODSUMOWANIA JEDNOSTKOWYCH KWOT PODATKU."
Mówiąc po ludzku, VAT poprawny jest zarówno jako suma zaokrągleń jak i
zaokrąglenie sumy - a że nie jest to to samo, nasz problem (trzeba
oprogramować wszzyskie przypadki...)
Generalnie zachęcam do lektury przepisów, księgowi nie zawsze są dobrym
źródłem wiedzy.
--
Pozdrawiam
Andrzej Małyszko
mobile 602680793
http://www.omnicomputer.com.pl
Dariusz Drzemicki
news:evsbq05o0uc26ajsh...@4ax.com...
> Mam na myśli sposób liczenia VAT na dokumentach typu FV.
> Taka wartości vat, o której dyskutujecie, obliczana dla pojedyńczej
> pozycji dokumentu w dowolny sposób, czyli: polem "kalkulowanym" czy
> triggerem czy jeszcze inaczej, może mieć zastosowanie jedynie
> pomocnicze, np: w rachunkowści ale zarządczej lub innych wynalazkach
> jak te kostki decyzyjne, ale napewno nie do rejestrów VAT!
Nie mówiliśmy o rejestrach, ale o zapisywaniu pozycji rachunku, zarówno
sprzedaży (może się tylko wyliczać), jak i zakupu (może się wyliczać, ale
jest potrzeba poprawki).
> A to, dlatego, że suma zaokrągleń składników nie musi dać takiego
> samego wyniku jak zakrąglenie sumy tychże składników.
> Vat, szanowni Panowie liczy się inaczej.
> Wpierw się grupuje dokumenty według stawki VAT potem sumuje w tych
> grupach i dopiero z tych sum wylicza się VAT. Natomiast VAT dla
> poszczególnych pozycji FV można wyliczać jak ktoś chce ale tylko w
> innych celach tzn. nie na potrzeby księgowości.
To już się zmieniło. VAT na rachunku może być liczony od sumy netto, jak i
może być sumą VAT pozycji.
DD
szaman
Widzę, że się zmieniło.
System sprzedaży pisałem jeszcze w Delphi 4.
Jednak fakt nierówności tych kwot o których mowa może prowadzić do
rozbieżności - szczególnie na styku dwóch programów.
Zaniepokoiła mnie ta możliwość i potrzeba korekt. Czy to tez
dozwolone?
Jest jeszcze sprawa pokrewna, mianowicie, gdy na fakturze towary są
zgrupowane w jedną pozycję ponieważ maja taką samą nazwę i cenę, a w
bazie danych jest to szereg rekordów (z jakiegoś tam powodu np. bo są
z różnych dostaw) i teraz VAT wyliczony na fakturze z tej zagregowanej
będzie różny od tego, który zostanie policzony przez trigger dla
każdego pojedyńczego rekordu.
To i tak może nie mieć znaczenia póki jak wspomniałem do rozliczeń
VAT-u bierze sie kwoty z faktur a te kwoty przy poszczególnych
pozycjach do innych mniej zobowiązujących celów gdzie poszczególne
grosze czy nawet złotówki a szczególnie ich bilansowanie, mają
mniejsze znaczenie.
Trzeba być po prostu uważnym bo czasem z tych zaokrągleń mogą wyjść
niezłe kwoty.
Tak dla checy weźmy przykład 100.000 śrubek po dwa grosze.
Kupiłeś je w dostawie i liczysz VAT od całości. Natomiast sprzedajesz
pojedyńczo i wychodzi ci zawsze VAT równy ZERO. ;-)
Dariusz Drzemicki
> Jednak fakt nierówności tych kwot o których mowa może prowadzić do
> rozbieżności - szczególnie na styku dwóch programów.
> Zaniepokoiła mnie ta możliwość i potrzeba korekt. Czy to tez
> dozwolone?
Mogą być rozbieżności. VAT w podsumowaniu faktury jest ważny, bo idzie do
rejestru. VAT w pozycjach może być tylko orientacyjny.
> Jest jeszcze sprawa pokrewna, mianowicie, gdy na fakturze towary są
> zgrupowane w jedną pozycję ponieważ maja taką samą nazwę i cenę, a w
> bazie danych jest to szereg rekordów (z jakiegoś tam powodu np. bo są
> z różnych dostaw) i teraz VAT wyliczony na fakturze z tej zagregowanej
> będzie różny od tego, który zostanie policzony przez trigger dla
> każdego pojedyńczego rekordu.
Oczywiście. VAT powinien być liczony od zagregownej pozycji na rachunku. VAT
z pozycji magazynowych jest tylko orientacyjny.
> To i tak może nie mieć znaczenia póki jak wspomniałem do rozliczeń
> VAT-u bierze sie kwoty z faktur a te kwoty przy poszczególnych
> pozycjach do innych mniej zobowiązujących celów gdzie poszczególne
> grosze czy nawet złotówki a szczególnie ich bilansowanie, mają
> mniejsze znaczenie.
> Trzeba być po prostu uważnym bo czasem z tych zaokrągleń mogą wyjść
> niezłe kwoty.
> Tak dla checy weźmy przykład 100.000 śrubek po dwa grosze.
> Kupiłeś je w dostawie i liczysz VAT od całości. Natomiast sprzedajesz
> pojedyńczo i wychodzi ci zawsze VAT równy ZERO. ;-)
Nie liczy się VATu od sztuki, ale od pozycji na rachunku lub od sumy kwoty
netto.
DD
szaman
Za mało przecinków i pare zgubionych słów.
szaman
>Nie liczy się VATu od sztuki, ale od pozycji na rachunku lub od sumy kwoty
>netto.
No ale gdy pozycja to właśnie sztuka?
Dałem taki ekstremalny przypadek jako ciekawostkę. Nie zamierzam abyś
ten problem próbował eozwiązać, Niech firmy sobie to robią same.
Chodziło tylko o ekstremalny przypadek błędów zaokrągleń prowadzących
do absurdu braku VAT.
Problem podziału materiału i tak pozostaje i błędów zaokrągleń VAT z
nim związanych - ceny wcale nie muszą być tak małe.
No ale to już chyba nie temat delphi i baz danych.
EOT
Dariusz Drzemicki
> Chodziło tylko o ekstremalny przypadek błędów zaokrągleń prowadzących
> do absurdu braku VAT.
Ten ekstremalny przypadek wynika z tego, że zaokrąglenie jest większe niż
kwota VAT w pozycji. Formalnie taki rachunek na 100 000 pozycji po 1 gr. z
zerowym VATem byłby zgodny z wykładnią ponującego prawa. Co innego
interpratacja urzędnika skarbowego.
DD
babla
> Wpierw się grupuje dokumenty według stawki VAT potem sumuje w tych
> grupach i dopiero z tych sum wylicza się VAT. Natomiast VAT dla
> poszczególnych pozycji FV można wyliczać jak ktoś chce ale tylko w
> innych celach tzn. nie na potrzeby księgowości.
pozdrawiam...
Andrzej Wąsik
babla
1 gr dla VAT
10 gr dla PIT
1 zl dla VAT-7
czyli VAT dla śrubki po 2 gr będzie wynosił 1 gr
... a ponieważ nikt nie lubi płacić wysokich podatków - nikt nie
sprzedaje śrubek na sztuki ;o)
pozdrawiam...
Andrzej Wąsik
Tomek Z
> O ile mnie pamięć nie myli podatki muszą być zaokrąglone w górę do
> 1 gr dla VAT
> 10 gr dla PIT
> 1 zl dla VAT-7
>
> czyli VAT dla śrubki po 2 gr będzie wynosił 1 gr
> .... a ponieważ nikt nie lubi płacić wysokich podatków - nikt nie
> sprzedaje śrubek na sztuki ;o)
>
> pozdrawiam...
> Andrzej Wąsik
Witam.
Z tego co wiem to tak zaokrąla się powyższe podatki, ale dalej stosuje się
regułę matematyczną, że:
0-0.499...gr = 0 gr
>=0.5 gr= 1 gr.
Jeżeli się mylę to proszę mnie poprawić ;)
Tomek
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
babla
fiskalnej.
... po drugie, jeśli sprzedaje się towar na sztuki, to każdy egzemplarz
musi mieć metkę (producent, kraj pochodzenia, sprzedawca etc), a nie
wyobrażam sobie, że każda śrubka będzie metkowana (koszt metki większy
niż 1 gr.). żeby uniknąć metkowania każdej sztuki towar jednorodny
sprzedaje się ilościowo i nadaje się jedna metkę.
pozdrawiam
Andrzej Wąsik
marcin
o nicg dowiedziec - moze to by mi ułatwiło pewne sprawy . Czy mogłbys mi
wskazac jakies żródła? ..bybym zobowiązany ..
Pozdrawiam
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Dariusz Drzemicki
news:5d7a.000007...@newsgate.onet.pl...
> Czesc - nie uzywam rekursywnych triggerów choz uzywam MSSql-qi chciałem
> sie cos
> o nicg dowiedziec - moze to by mi ułatwiło pewne sprawy . Czy mogłbys mi
> wskazac jakies żródła? ..bybym zobowiązany ..
Ustawia się je w opcjach bazy.
Różnią się od zwykłach tylko tym, że modyfikacje w triggerach uruchamiają
dalej triggery.
Idea polega na tym, że łączę reguły ze zdarzeniem w tabeli bez względu na
to, czy dokonało się ono w triggerze, czy poza nim.
DD