Front-End dla MS Access migration? [zamknięte]

Kilka lat temu zmieniłem back-end jednej aplikacji z MSacces na MSSQL. Trzymałem front-end, ponieważ działał dobrze, a ja nie znalazłem nic tak łatwego w użyciu/modyfikacji.

Nigdy nie widziałem MSAccess -> C# translator. Można jednak znaleźć MSAccess do tłumacza VB6 (ich składnia jest z grubsza podobna), a stamtąd są VB6 - >VB.Net Tłumacze (a nawet VB.Net ->Tłumacze C#)

Więc, poza osobistym niesmakiem, po co wymieniać front-end Access? Może to być łatwe do zrobienia dla niektórych (prostych) baz danych, ale większość aplikacji dostępowych w świecie rzeczywistym ma wiele złożoności.

Wiele powodów do aktualizacji back-endu, oczywiście (skalowalność, wydajność, korupcja db, blokowanie użytkownika). Access ma nawet wbudowane narzędzie "Kreator aktualizacji", które pozwala podzielić formularze i logikę z danych i uaktualnić dane do MS SQL server. Jeśli chcesz, Użyj tego kreatora, aby uaktualnić back-end do SQL Express, a następnie ręcznie migrować do innej platformy db.

Mam nadzieję, że nie jest to zbyt daleko od tematu, ale czasami wszystko, co musisz zrobić z dostępem, To:

1. Uaktualnij back-end (jak już omówiliśmy)

2. Zawsze upewnij się, że front-endy są zablokowane (tylko do odczytu)

3. W razie potrzeby utwórz różne interfejsy dla różnych ról użytkowników (jako formę bezpieczeństwa).

4. Jeśli to możliwe, skopiuj front-endy lokalnie na każdej stacji roboczej, ze względu na wydajność. Może być konieczne posiadanie skryptu sieciowego, aby sprawdzić nowe wersje front-endu.

Nie mam z tym bezpośredniego doświadczenia, ale znalazłem dostęp do ASP.Net narzędzie konwertera o nazwie "access Whiz" at http://www.microtools.us/

Użyliśmy wewnętrznej aplikacji opartej na MS Access jako nakładki do bazy danych MySQL. Napotkaliśmy wiele problemów i ostatecznie przepisaliśmy całą aplikację w CodeGear Delphi 2007 dla Win32 . To był wielki sukces, chociaż migracja kosztowała sporo wysiłku (szkolenie/Zatrudnienie kilku programistów Delphi, zakup narzędzi innych firm). Z całego serca mogę jednak polecić Delphi. A AFAIK, integracja z back-endem MS Access jest z pewnością możliwa - - - I kiedyś napisałem aplikację Delphi, która właśnie to robi i kosztowało mnie tylko kilka dni, aby uzyskać pełną wersję funkcji!

Zdaję sobie sprawę, że jest to pełne rozwiązanie programistyczne, więc zdecydowanie stracisz trochę łatwości użycia MS Access do budowania front-endów. Z drugiej strony, możesz złożyć aplikację bazodanową w Delphi w 10 minut bez pisania zbyt dużo kodu - - - nie żartuj! A od wydania z 2009 roku, język powoli staje się coraz bardziej mainstreamowy...

@BradC

Nie polecam MicroTools. Pracowałem w firmie, gdzie mieliśmy ten sam problem. O ile MicroTools nie wprowadził znaczących ulepszeń w swoim produkcie, wypluwa śmieci ostatnio, gdy sprawdzałem.

Okazało się, że praktycznie każda ścieżka aktualizacji będzie wymagała znacznych ilości zmian w kodowaniu. Wszystkie te narzędzia są dobre dla jest utrzymanie podobnego GUI z oryginalnej aplikacji. Ich kod nie miał struktury obiektowej, tylko kilka użytecznych funkcje, które zostały rzucone na każdej stronie, aby symulować sposób dostępu zapewnia nawigację rekordów. Jeśli masz dużą liczbę formularzy, wyciągnięcie ich rozwiązania i wdrożenie własnego wymaga trochę pracy i mnóstwa operacji znajdź i zamień.

Byliśmy tak rozczarowani wydajnością MicroTools, że zaczęliśmy pisać własny konwerter. Wypompowywaliśmy się lepiej ASP.NET formularze niż po tygodniu kodowania.

Nie znajdziesz silnika klasy serwerowej , który ma również dołączone narzędzia do projektowania interfejsu pulpitu. Duże silniki serwerowe oczekują, że do budowy interfejsu użyjesz czegoś takiego jak C++, C#, Java lub PHP.

Ja też chciałbym zobaczyć narzędzie do aktualizacji dostępu, które wypluwa podstawowe formularze C# i rozmawia z równoważną bazą danych SQL Server. Wydaje się, że byłby to duży zarobek dla Microsoftu, ponieważ mogliby go wykorzystać jako sposób na sprzedaż klientów do pełnego SQL Server.

IIRC, może być sposób, aby powiedzieć front-end dostęp do rozmowy z serwerem SQL, lub zmienić tabele używane przez front-end dostęp naprawdę być połączone tabele w SQL Server, lub coś w tym stylu, ale nigdy nie musiałem korzystać z funkcji sam.

Mam dla Ciebie inną perspektywę do rozważenia. Twoim głównym problemem jest to, że ukrywa logikę, a Dane i aplikacje są rozproszone po organizacji.

Niestety nie znam narzędzia RAD (rapid application development), które jest tak łatwe, jak dostęp do tworzenia funkcjonalnych formularzy.

Zalecałbym jednak, abyś skupił się bardziej na możliwości centrowania danych i logiki i nadal zezwalał na dostęp jako front end. Obsługuję produkt bazodanowy o nazwie Advantage Database Server obsługujący reguły ri (refferential integrity), procedury składowane, wyzwalacze itp. to wszystko może być zarządzane na serwerze centeral w ten sposób przynosząc całą logikę do ciebie. Te interfejsy dostępu mogą następnie połączyć się z backendem danych za pomocą ODBC lub OLEDB. Jeśli przełączysz się na takie rozwiązanie, to później będziesz miał elastyczność pisania innych aplikacji, takich jak.NET, PHP, JDBC itp. które wiążą się z tymi samymi danymi podczas fazowania dostępu.

Dobrym początkiem byłoby wstrzymanie rozwoju nowego dostępu, chyba że używają tego rodzaju backendu danych.

Z 1000 Plików dostępu, ile z nich zostało poproszonych o wsparcie? Zgaduję, że mniej niż 100. Po co przebudowywać aplikację, której A) nikt nie używa B) działa dobrze tak jak jest?

Musisz rozpocząć politykę, że akceptowalną praktyką dla dużej organizacji jest tworzenie niestandardowych aplikacji w solidnym, skalowalnym, niezawodnym środowisku yadda yadda yadda yadda. Zidentyfikuj aplikacje dostępowe, które uważasz za krytyczne lub które są wyrosłe, i po prostu pracuj nad nimi.

Be przygotowani do obsługi oczekiwania na szybkie i brudne małe aplikacje na szybki zwrot. Będziesz musiał pokazać im zalety nowych aplikacji.

Myślę, że po prostu trzeba być ekspertem rezydenta i nauczyć tych użytkowników, jak poprawić swoją aplikację lub uzyskać swój wkład od początku, aby rozpocząć je dobrze. W przeciwnym razie wymagania dotyczące konwersji wszystkich tych plików byłyby przytłaczające.

Microtools oferuje access Whiz, zestaw narzędzi do konwersji dostępu. Składa się z dostępu do konwerterów ASP. net (VB/C#), dostępu do konwertera VB6, dostępu do konwerterów WinForms (VB.Net/C#) oraz dostępu do konwertera Crystal Reports. Więcej informacji i demo wersji próbnych można znaleźć na stronie http://www.microtools.us .

Możesz również spojrzeć na Firebird

Oto sposób na migrację (potrzebujesz Delphi)

Znajduję również to MDB2FDB

Czy jest coś, co zastąpi przednią część MS Access?

Może Kexi ?