>> 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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

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

do góry

[...]

> 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

do góry

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

do góry