Witam,
Problem do rozwiązania jest następujący:
jest sobie baza danych która waży ok. 100MB. Przechowywana jest na komputerze 1. W tej chwili komputer 2 i 3 korzystający z tej bazy łączy się (sieć lokalna) z bazą danych z komputera pierwszego. Skutek jest taki, że na komputerach 2 i 3 program 'zamula'. W tej chwili mam switche 10/100. Informatycy mówią że troszkę może pomóc wymiana switcha na gigabitowy. Faktycznie to coś da, czy może da się w jakiś sposób przechowywać te bazy lokalnie i je razem łączyć (wszystkie komputery odczytują i zapisują dane w tej bazie). Dwa z komputerów stoją koło siebie i na nich zależy mi żeby to chodziło szybko, trzeci sporadycznie używany może nadal się ślimaczyć - może jakoś dodatkowo je połączyć?

--
Pozdrawiam
Łukasz

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na

Co to za baza?

komputerze 1. W tej chwili komputer 2 i 3 korzystający z tej bazy łączy się (sieć lokalna) z bazą danych z komputera pierwszego. Skutek jest taki, że na komputerach 2 i 3 program 'zamula'. W tej chwili mam switche 10/100. Informatycy mówią że troszkę może pomóc wymiana switcha na gigabitowy. Faktycznie to coś da, czy może da się w jakiś sposób przechowywać te bazy lokalnie i je razem łączyć (wszystkie komputery odczytują i zapisują dane w tej bazie). Dwa z komputerów stoją koło siebie i na nich zależy mi żeby to chodziło szybko, trzeci sporadycznie używany może nadal się ślimaczyć - może jakoś dodatkowo je połączyć?

To nie ma sensu. Baza w sieci to najnormalniejsza normalnosac, popraw wydajnosc sieci i
byc moze tego komputera, serwera (ram, szybki dysk).

poza tym NTG

--
pozdro
R.e.m.e.K

W dniu 24.10.2014 o 18:39, R.e.m.e.K pisze:

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na

Co to za baza?

komputerze 1. W tej chwili komputer 2 i 3 korzystający z tej bazy łączy
się (sieć lokalna) z bazą danych z komputera pierwszego. Skutek jest
taki, Ĺźe na komputerach 2 i 3 program 'zamula'. W tej chwili mam switche
10/100. Informatycy mówią że troszkę może pomóc wymiana switcha na
gigabitowy. Faktycznie to coś da, czy może da się w jakiś sposób
przechowywać te bazy lokalnie i je razem łączyć (wszystkie komputery
odczytują i zapisują dane w tej bazie). Dwa z komputerów stoją koło
siebie i na nich zależy mi żeby to chodziło szybko, trzeci sporadycznie
używany może nadal się ślimaczyć - może jakoś dodatkowo je połączyć?

To nie ma sensu. Baza w sieci to najnormalniejsza normalnosac, popraw wydajnosc sieci i
byc moze tego komputera, serwera (ram, szybki dysk).

poza tym NTG

No chyba, ze pyta jaki hardwarowy serwer pod baze wybrac, zeby ja przeniesc na serwer ;)

Wtedy bedzie mu zamulać równo z wszystkich komputerów :D Bo najwyraźniej problem tkwi w zdalnych klientach ;)

--
Mr Misio De Grizzly Casual Player PC/PS3 Howgh!

http://fb.com/termopilecom

W dniu 2014-10-24 19:07, mr misio de grizzly pisze:

W dniu 24.10.2014 o 18:39, R.e.m.e.K pisze:

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych która waży ok. 100MB. Przechowywana jest na

Co to za baza?

komputerze 1. W tej chwili komputer 2 i 3 korzystający z tej bazy łączy
się (sieć lokalna) z bazą danych z komputera pierwszego. Skutek jest
taki, że na komputerach 2 i 3 program 'zamula'. W tej chwili mam switche
10/100. Informatycy mówią że troszkę może pomóc wymiana switcha na
gigabitowy. Faktycznie to coś da, czy może da się w jakiś sposób
przechowywać te bazy lokalnie i je razem łączyć (wszystkie komputery
odczytują i zapisują dane w tej bazie). Dwa z komputerów stoją koło
siebie i na nich zależy mi żeby to chodziło szybko, trzeci sporadycznie
używany może nadal się ślimaczyć - może jakoś dodatkowo je połączyć?

To nie ma sensu. Baza w sieci to najnormalniejsza normalnosac, popraw
wydajnosc sieci i
byc moze tego komputera, serwera (ram, szybki dysk).

poza tym NTG

No chyba, ze pyta jaki hardwarowy serwer pod baze wybrac, zeby ja
przeniesc na serwer ;)

Wtedy bedzie mu zamulać równo z wszystkich komputerów :D Bo najwyraźniej
problem tkwi w zdalnych klientach ;)

E, tam.
Nie takie bazy były i to jeszcze na Novellach, na kablu RG58, z klientami DOS-owymi. I bywało, że w sieci miałem ponad 60 ludków.

Ewidentnie problem z bazą.
Co to za baza i dlaczego nie pracuje jako client-server?


--
Pozdrawiam.

Adam

To nie ma sensu. Baza w sieci to najnormalniejsza normalnosac, popraw wydajnosc sieci i
byc moze tego komputera, serwera (ram, szybki dysk).

Dokladnie.

Bo najwyraĹşniej problem tkwi w zdalnych klientach ;)

Raczej nie, ale byc moze po sieci fruwaja strasznie nieoptymalnie zapytania.

W dniu 2014-10-25 10:30, jakson pisze:

To nie ma sensu. Baza w sieci to najnormalniejsza normalnosac, popraw
wydajnosc sieci i
byc moze tego komputera, serwera (ram, szybki dysk).

Dokladnie.

Bo najwyraźniej problem tkwi w zdalnych klientach ;)

Raczej nie, ale byc moze po sieci fruwaja strasznie nieoptymalnie
zapytania.

E, tam. Stawiam skrzynkę piwa, że po jego sieci ganiają nie zapytania, tylko cała baza.


--
Pozdrawiam.

Adam

Użytkownik "Adam"  napisał w wiadomości grup dyskusyjnych:m2ja61$u24$2@usenet.news.interia.pl...


E, tam. Stawiam skrzynkę piwa, że po jego sieci ganiają nie zapytania,
tylko cała baza.


za każdym razem całość, tak, tak może być

W dniu 2014-10-24 18:39, R.e.m.e.K pisze:

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na

Co to za baza?

sorry że się nie odzywałem, ale mam dużo pracy
oprogramowanie KC-Firma, obsługa sklepu, na pierwszym komputerze serwer łączy się z kasami/wagami i przechowuje na dysku bazę danych. Na innych komputerach katalog z bazą danych został udostępniony jako wirtualny dysk

--
Pozdrawiam
Łukasz

W dniu 2014-10-29 o 17:26, dddddddd pisze:

W dniu 2014-10-24 18:39, R.e.m.e.K pisze:

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na

Co to za baza?

sorry że się nie odzywałem, ale mam dużo pracy
oprogramowanie KC-Firma, obsługa sklepu, na pierwszym komputerze serwer
łączy się z kasami/wagami i przechowuje na dysku bazę danych. Na innych
komputerach katalog z bazą danych został udostępniony jako wirtualny dysk

Wygląda mi to na stareńką technologię Microsoft Visual Basic for Applications i baza plikowa w formacie Access. Dużo z tym nie zrobisz. Szczególnie że Access wyjątkowo słabo znajdował się w sieci. Trochę może przyśpieszyć wymiana sieci na Gigabitową.

miab

Co to za baza?

sorry że się nie odzywałem, ale mam dużo pracy
oprogramowanie KC-Firma, obsługa sklepu, na pierwszym komputerze serwer
łączy się z kasami/wagami i przechowuje na dysku bazę danych. Na innych
komputerach katalog z bazą danych został udostępniony jako wirtualny dysk

Dalej to nie jest odpowiedź co to za baza i w jaki sposób jest skonfigurowany dostęp do niej.
Może być tak:
-komputer traktuje plik bazy jako zwykły plik, wtedy każde otwarcie bazy łączy się z jej ściągnięciem na lokalny komputer i tam praca na niej, zapis to uaktualnianie całości itd.
-komputer traktuje bazę jako bazę, na komputerze na którym jest ona zainstalowana jest oprogramowanie serwerowe, które rozumie wysyłane z komputera klienckiego zapytania i na te zapytania odpowiada. Wtedy po sieci nie biega cała baza a jedynie dane, które są odczytywane, zapisywane. O to co gdzie zapisać dba oprogramowanie serwerowe, obsługujące bazę.

Teoretycznie soft obsługuje zapytania klient-serwer (z manualki):
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Użyte narzędzia:
Główne moduły kodu zostały napisane w języku MS Visual Basic for Applications pakietu MS Access 97 (MS Office Developer Edition) oraz Borland C++ 5.01. Wszystkie programy są samodzielnymi aplikacjami (nie jest konieczne posiadanie licencji na MS Access).
Baza danych:
Zastosowano bazę danych w formacie Access 97. Dane magazynu przechowywane są w jednym pliku. Maksymalna wielkość pliku bazy danych wynosi 1GB. Baza danych obsługiwana jest transakcyjnie.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Tylko teraz pytanie jak są skonfigurowane stacje, poczytaj tu:
http://www.kucharscy.com.pl/?page_id=5#dokumentacja
i sprawdź. Jak Access i to jeszcze w wersji 97, to duża szansa, że całe pliki latają po sieci i dlatego działa wolno.
Pozdr.
Przem

W dniu 2014-10-29 o 17:26, dddddddd pisze:

W dniu 2014-10-24 18:39, R.e.m.e.K pisze:

Dnia Fri, 24 Oct 2014 18:02:28 +0200, dddddddd napisał(a):

jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na

Co to za baza?

sorry że się nie odzywałem, ale mam dużo pracy
oprogramowanie KC-Firma, obsługa sklepu, na pierwszym komputerze serwer
łączy się z kasami/wagami i przechowuje na dysku bazę danych. Na innych
komputerach katalog z bazą danych został udostępniony jako wirtualny dysk

Podejrzewam, że na komputerach macie Visty albo coś nowszego.
Niestety, ale oznacz to że nic nie można zrobić.

Microsoft wprowadzając Windows Vista dokonał rewolucji
w protokole sieciowym stosowanym przez systemy Windows.
Wcześniej SMB (Server Message Block) posiadał
ponad 100 róşnych niskopoziomowych komend
pozwalających na zdalny dostęp do plików.
We wszystkich wersjach po Viście liczba ta został zredukowana
do zaledwie 19 podstawowych operacji.
(http://blogs.technet.com/b/josebda/archive/2008/12/05/smb2-a-complete-redesign-of-the-main-remote-file-protocol-for-windows.aspx)

Kiedyś można było zdalnie zablokować fragment pliku,
pobrać kilka bajtów ze środka, zmienić je.
Wszystko bez potrzeby przesyłania całego pliku.
Aktualnie w Windows nie ma już takiej możliwości,
pozostała już tylko opcja przesyłania prze sieć całych plików.
System dalej udaje że jest w stanie zdalnie modyfikować fragment pliku
ale tylko udaje, za każdym razem musi pobrać i odesłać cały plik,
dla programu nie ma to znaczenia, po prostu jest wolniejsze,
dla użytkownika, program korzystający z bazy
udostępnionej na współdzielonym folderze sieciowym
stał się bezużyteczny.

6 lat temu, kiedy nastąpił ta zmiana pracowałem w firmie
gdzie pisaliśmy programy korzystające właśnie z plików accessowych
jako lokalnej bazy danych.
Nasza aplikacja na starcie odczytywała kilka podstawowych informacji
z takiego pliku.
Na Windows 2000 i XP było to błyskawiczne,
ale na Viscie, aby odczytać te podstawowe informacje z 20 MB pliku
komputer musiał przez sieć przepchnąć ponad 500 MB danych.
Przy sieci 100 Mbps był to koszmar.
Dla naszej firmy oznaczało to tylko jedno,
przez kilak miesięcy cały dział developmentu
musiało przerobić wszystkie nasze programy tak
aby nie korzystały z Accessa (plików MDB)
i przerzuciły się na MS SQL-a 2005 Express
Żaden mechanizm oparty o współdzielony folder nie działał.

/Robert

Użytkownik "Robert Winkler" napisał:

Kiedyś można było zdalnie zablokować fragment pliku,
pobrać kilka bajtów ze środka, zmienić je.
Wszystko bez potrzeby przesyłania całego pliku.
Aktualnie w Windows nie ma już takiej możliwości,
pozostała już tylko opcja przesyłania prze sieć całych plików.

Nie każda Winda to umożliwiała. Jeśli dobrze pamiętam to tylko Windows Serwer. "Zwykła" winda wczytuje cały plik do pamięci:

CreateFile, ReadFile, GetWindowText

po edycji pliku jest on zapisywany jako całość odwrotnymi funkcjami, a to trwa. Obsługa bazy danych na Windows to nieporozumienie.

Pzdr

Dnia Fri, 31 Oct 2014 10:11:11 +0100, Kamil napisał(a):

Obsługa bazy danych na Windows to nieporozumienie.

Accessa czy kazdej bazy?

--
pozdro
R.e.m.e.K

W dniu 2014-10-31 o 11:22, R.e.m.e.K pisze:

Dnia Fri, 31 Oct 2014 10:11:11 +0100, Kamil napisał(a):

Obsługa bazy danych na Windows to nieporozumienie.

Accessa czy kazdej bazy?

Dotyczy jakiegokolwiek pliku do którego dostajesz się zdalnie.
Nie ważne czy odwołujesz się przez \\server\shared_folder\file.db
czy teĹź najpierw zamapujesz \\server\shared_folder\ jako dysk u siebie
i poprzez zamapowany dysk odwołujesz się do niego.

Wszystko było dobrze w Windows 3.11 for Workgroup,
w Windows 95, 98, NT4, 2000 czy teĹź XP.

CreateFile, ReadFile, GetWindowText to funkcje WinAPI
CreateFile, ReadFile pracują na uchwycie pliku, dla nich nie jest ważne
czy plik znajduje się lokalnie, czy zdalnie, zawsze działają tak samo.
Dopiero pod spodem, gdy jest to plik plik lokalny na dysku NTFS
zamieniane to jest na operacje NTFSa
czy jest to SCSI, system tłumaczy to na komendy SCSI,
gdy jest to plik zdalny do którego dostęp odbywa się przez WebDAV
zamieniane to jest na komendy HTTP
gdy jest to plik w sieci lokalnej zamieniane to jest na komendy SMB.
I tu jest właśnie problem, stare SMB posiadało funkcje zbliżone do tych
oferowanych przez dyski lokalne,
w SMB v2 wszystko to zostało usunięte i mamy tylko:
NEGOTIATE, SESSION_SETUP, LOGOFF, TREE_CONNECT,
TREE_DISCONNECT
CANCEL, CHANGE_NOTIFY, CLOSE, CREATE, FLUSH,
IOCTL, LOCK, QUERY_DIRECTORY, QUERY_INFO,
READ, SET_INFO, WRITE
ECHO, OPLOCK_BREAK

Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dyskĂłw sieciowych za kaĹźdym razem gdy program uĹźywa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

/Robert

W dniu 2014-10-31 o 13:12, Robert Winkler pisze:

W dniu 2014-10-31 o 11:22, R.e.m.e.K pisze:

Dnia Fri, 31 Oct 2014 10:11:11 +0100, Kamil napisał(a):

Obsługa bazy danych na Windows to nieporozumienie.

Accessa czy kazdej bazy?

Dotyczy jakiegokolwiek pliku do którego dostajesz się zdalnie.
Nie ważne czy odwołujesz się przez \\server\shared_folder\file.db
czy teĹź najpierw zamapujesz \\server\shared_folder\ jako dysk u siebie
i poprzez zamapowany dysk odwołujesz się do niego.

Wszystko było dobrze w Windows 3.11 for Workgroup,
w Windows 95, 98, NT4, 2000 czy teĹź XP.

CreateFile, ReadFile, GetWindowText to funkcje WinAPI
CreateFile, ReadFile pracują na uchwycie pliku, dla nich nie jest ważne
czy plik znajduje się lokalnie, czy zdalnie, zawsze działają tak samo.
Dopiero pod spodem, gdy jest to plik plik lokalny na dysku NTFS
zamieniane to jest na operacje NTFSa
czy jest to SCSI, system tłumaczy to na komendy SCSI,
gdy jest to plik zdalny do którego dostęp odbywa się przez WebDAV
zamieniane to jest na komendy HTTP
gdy jest to plik w sieci lokalnej zamieniane to jest na komendy SMB.
I tu jest właśnie problem, stare SMB posiadało funkcje zbliżone do tych
oferowanych przez dyski lokalne,
w SMB v2 wszystko to zostało usunięte i mamy tylko:
NEGOTIATE, SESSION_SETUP, LOGOFF, TREE_CONNECT,
TREE_DISCONNECT
CANCEL, CHANGE_NOTIFY, CLOSE, CREATE, FLUSH,
IOCTL, LOCK, QUERY_DIRECTORY, QUERY_INFO,
READ, SET_INFO, WRITE
ECHO, OPLOCK_BREAK

Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dyskĂłw sieciowych za kaĹźdym razem gdy program uĹźywa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Klient tego nie umie czy serwer czy obydwaj (od Visty)?
Bo jak serwer to można by postawić XP SERVER albo Sambe na Linux-ie.

miab

[...]

Klient tego nie umie czy serwer czy obydwaj (od Visty)?
Bo jak serwer to można by postawić XP SERVER albo Sambe na Linux-ie.

Najlepiej było by na obu maszynach wyłączyć SMB v2
Tu jest opis jak to zrobić:
http://support.microsoft.com/kb/2696547

/Robert

W dniu 2014-10-31 13:12, Robert Winkler pisze:

(...)
Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dysków sieciowych za każdym razem gdy program używa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Czyli, gdybym w swoich archiwach odszukał jakąś bazę Clipperową, która spokojnie pracowała pod NW3.12 z 60+ stanowiskami, to "zgniótłbym" współczesną sieć peer-to-peer z kilkoma stanowiskami Win7 na sieci 1000MB?


A wiesz może, jak wygląda sprawa z Pervasive SQL?
A konkretnie CDN-Klasyka FPP c/s?
Bo wydaje mi się, że tak naprawdę to nie było client/server, ale jakoś nigdy nie miałem czasu/chęci aby to sprawdzać.
W każdym razie było wyraźnie wydajniejsze i szybsze, niż to samo FPP pracujące na bazach Clariona.


--
Pozdrawiam.

Adam

W dniu 2014-10-31 o 14:29, Adam pisze:

W dniu 2014-10-31 13:12, Robert Winkler pisze:

(...)
Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dysków sieciowych za każdym razem gdy program używa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Czyli, gdybym w swoich archiwach odszukał jakąś bazę Clipperową, która
spokojnie pracowała pod NW3.12 z 60+ stanowiskami, to "zgniótłbym"
współczesną sieć peer-to-peer z kilkoma stanowiskami Win7 na sieci 1000MB?

Spokojnie dostał byś aż by się kurzyło od każdej prawidłowo napisanej aplikacji w architekturze klient serwer(SQL).

miab

W dniu 2014-10-31 14:33, miab pisze:

W dniu 2014-10-31 o 14:29, Adam pisze:

W dniu 2014-10-31 13:12, Robert Winkler pisze:

(...)
Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dysków sieciowych za każdym razem gdy program używa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Czyli, gdybym w swoich archiwach odszukał jakąś bazę Clipperową, która
spokojnie pracowała pod NW3.12 z 60+ stanowiskami, to "zgniótłbym"
współczesną sieć peer-to-peer z kilkoma stanowiskami Win7 na sieci
1000MB?

Spokojnie dostał byś aż by się kurzyło od każdej prawidłowo napisanej
aplikacji w architekturze klient serwer(SQL).

? Nie rozumiem.
Pytałem o program clipperowski, czyli na bazach dbf. Czyli z czasów DOS-a 3.30 - jeszcze nikomu chyba się nie śniły aplikacje c/s.

Natomiast "trochę" ;) rozeznania mam w aplikacjach SQL.
Przykładowo:
CDN-Optima (teraz Comarch Optima) w starej wersji 17.x śmigała aż miło.
Pracowała na MS-SQL 2000+.
Później aplikacja została przepisana z Clariona na dotNeta - wersja 2010.x - bardzo słabo to chodziło, dużo zapytań było po stronie klienta.
Optymalizacja była w wersjach 2012.x - już jest dobrze (aktualnie 2014.6 na MS-SQL 2008+).

Porównywalna baza przykładowo na WF-Mag (MS-SQL2008) chodzi duuużo słabiej.
Porównywalna baza na Enova (firmy Soneta) śmiga, aż miło, lepiej od Optimy.


--
Pozdrawiam.

Adam

W dniu 2014-10-31 o 15:06, Adam pisze:

W dniu 2014-10-31 14:33, miab pisze:

W dniu 2014-10-31 o 14:29, Adam pisze:

W dniu 2014-10-31 13:12, Robert Winkler pisze:

(...)
Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dysków sieciowych za każdym razem gdy program używa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Czyli, gdybym w swoich archiwach odszukał jakąś bazę Clipperową, która
spokojnie pracowała pod NW3.12 z 60+ stanowiskami, to "zgniótłbym"
współczesną sieć peer-to-peer z kilkoma stanowiskami Win7 na sieci
1000MB?

Spokojnie dostał byś aż by się kurzyło od każdej prawidłowo napisanej
aplikacji w architekturze klient serwer(SQL).

? Nie rozumiem.
Pytałem o program clipperowski, czyli na bazach dbf. Czyli z czasów
DOS-a 3.30 - jeszcze nikomu chyba się nie śniły aplikacje c/s.

Śniło się bo sam mówisz o aplikacji c/s.
Chyba nie DOS bo piszesz o Novel-u.
A dokładniej np. ORACLE-owi w tym czasie się śniło to czego nie potrafisz prawidłowo nazwać.

Natomiast "trochę" ;) rozeznania mam w aplikacjach SQL.
Przykładowo:
CDN-Optima (teraz Comarch Optima) w starej wersji 17.x śmigała aż miło.
Pracowała na MS-SQL 2000+.
Później aplikacja została przepisana z Clariona na dotNeta - wersja
2010.x - bardzo słabo to chodziło, dużo zapytań było po stronie klienta.
Optymalizacja była w wersjach 2012.x - już jest dobrze (aktualnie 2014.6
na MS-SQL 2008+).

Porównywalna baza przykładowo na WF-Mag (MS-SQL2008) chodzi duuużo słabiej.
Porównywalna baza na Enova (firmy Soneta) śmiga, aż miło, lepiej od Optimy.

Mówiłem prawidłowo napisana.

miab

W dniu 2014-10-31 15:29, miab pisze:

W dniu 2014-10-31 o 15:06, Adam pisze:

W dniu 2014-10-31 14:33, miab pisze:

W dniu 2014-10-31 o 14:29, Adam pisze:

W dniu 2014-10-31 13:12, Robert Winkler pisze:

(...)
Nie ma już komendy SEEK, a był ona podstawową operacją
pozwalającą na poruszanie się wewnątrz pliku,
na pominięcie jego fragmentu i oczytanie tylko interesującej części.
Pracując z dyskiem lokalnym dysponujemy odpowiednikiem komendy SEEK,
dla dysków sieciowych za każdym razem gdy program używa seek
i próbuje odczytać lub zapisać kilka bajtów ze środka pliku
system musi to zasymulować przesyłając po sieci całość.
W końcu funkcja WinAPI SetFilePointer musi działać tak samo na każdym
systemie
a że w Windows 7 wymaga to przesłania po sieci całego pliku... trudno.

Czyli, gdybym w swoich archiwach odszukał jakąś bazę Clipperową, która
spokojnie pracowała pod NW3.12 z 60+ stanowiskami, to "zgniótłbym"
współczesną sieć peer-to-peer z kilkoma stanowiskami Win7 na sieci
1000MB?

Spokojnie dostał byś aż by się kurzyło od każdej prawidłowo napisanej
aplikacji w architekturze klient serwer(SQL).

? Nie rozumiem.
Pytałem o program clipperowski, czyli na bazach dbf. Czyli z czasów
DOS-a 3.30 - jeszcze nikomu chyba się nie śniły aplikacje c/s.

Śniło się bo sam mówisz o aplikacji c/s.
Chyba nie DOS bo piszesz o Novel-u.

Dalej nie rozumiem, o czym mówisz.
Programy bazodanowe siedziały najczęściej na serwerach, w tym NW3.11 czy NW3.12 (wbrew pozorom duża różnica). Natomiast pracowało się w środowisku DOS-owym, na 3.30 czy później 5.0.

A dokładniej np. ORACLE-owi w tym czasie się śniło to czego nie
potrafisz prawidłowo nazwać.

Ale czego nie potrafię nazwać?

Obsługiwałem też krótko aplikacje wielodostępowe, ale to było bodajże na AS/400 - zupełnie inna bajka.
Później wszedł NW4 i NW5 - już zupełnie co innego, niż zwykły file-server czy access server znany z NW3.x.
Dla "maluczkich" pojawił się Lantastic.

Ja obsługiwałem mniejsze firmy - gdzie im tam było do Oracla ;)

Natomiast "trochę" ;) rozeznania mam w aplikacjach SQL.
Przykładowo:
CDN-Optima (teraz Comarch Optima) w starej wersji 17.x śmigała aż miło.
Pracowała na MS-SQL 2000+.
Później aplikacja została przepisana z Clariona na dotNeta - wersja
2010.x - bardzo słabo to chodziło, dużo zapytań było po stronie klienta.
Optymalizacja była w wersjach 2012.x - już jest dobrze (aktualnie 2014.6
na MS-SQL 2008+).

Porównywalna baza przykładowo na WF-Mag (MS-SQL2008) chodzi duuużo
słabiej.
Porównywalna baza na Enova (firmy Soneta) śmiga, aż miło, lepiej od
Optimy.

Mówiłem prawidłowo napisana.

Zgadza się. Prawidłowo.
I z tym jest problem - trzeba mieć lata praktyki, aby potrafić zoptymalizować program. Trzeba wiedzieć, co zrobić, aby zapytanie odbywało się po stronie serwera a nie klienta.
Ale w tym specjalizuje się wloochacz.



--
Pozdrawiam.

Adam

Dnia Fri, 31 Oct 2014 13:12:32 +0100, Robert Winkler napisał(a):

W dniu 2014-10-31 o 11:22, R.e.m.e.K pisze:

Dnia Fri, 31 Oct 2014 10:11:11 +0100, Kamil napisał(a):

Obsługa bazy danych na Windows to nieporozumienie.

Accessa czy kazdej bazy?

Dotyczy jakiegokolwiek pliku do którego dostajesz się zdalnie.

Dzieki, ale pytanie bylo konkretnie do Kamila i o to co zasugerowal: "Obsługa bazy danych na Windows to nieporozumienie"

czyli, ze wg niego na windows da sie pracowac z bazami danych.

--
pozdro
R.e.m.e.K

Dnia Fri, 31 Oct 2014 16:46:55 +0100, R.e.m.e.K napisał(a):

Dzieki, ale pytanie bylo konkretnie do Kamila i o to co zasugerowal: "Obsługa bazy danych na Windows to nieporozumienie"

czyli, ze wg niego na windows da sie pracowac z bazami danych.

Fak, zezarlo mi slowo "nie" pomiedzy "windows" i "da", mialo byc:

" czyli, ze wg niego na windows nie da sie pracowac z bazami danych."


--
pozdro
R.e.m.e.K

W dniu 2014-10-24 o 18:02, dddddddd pisze:

Witam,
Problem do rozwiązania jest następujący:
jest sobie baza danych ktĂłra waĹźy ok. 100MB. Przechowywana jest na
komputerze 1. W tej chwili komputer 2 i 3 korzystający z tej bazy łączy
się (sieć lokalna) z bazą danych z komputera pierwszego. Skutek jest
taki, Ĺźe na komputerach 2 i 3 program 'zamula'. W tej chwili mam switche
10/100. Informatycy mówią że troszkę może pomóc wymiana switcha na
gigabitowy. Faktycznie to coś da, czy może da się w jakiś sposób
przechowywać te bazy lokalnie i je razem łączyć (wszystkie komputery
odczytują i zapisują dane w tej bazie). Dwa z komputerów stoją koło
siebie i na nich zależy mi żeby to chodziło szybko, trzeci sporadycznie
używany może nadal się ślimaczyć - może jakoś dodatkowo je połączyć?

Trudno wróżyć bez szklanej kuli.

miab