Paradox-tietokantojen modernisointi: reitit legacy-ympäristöstä ilman käyttöriskiä

Kuka tahansa, joka haluaa Paradox-tietokantojen modernisointia, ei yleensä kohtaa pelkkää teknologiakysymystä. Monissa yrityksissä Paradox on osa kehittynyttä prosessikenttää: työpöytäasiakkaat, tiedostopohjaiset taulukot, usein kytkettynä Borland Database Engine (BDE), lisäksi lukituksiin, verkkojaettuihin tallennusalueisiin ja historialliseen „kasvaneeseen“ dataperustaan liittyviä kiertoratkaisuja. Niin kauan kuin kaikki toimii, tämä rakenne siedetään. Tilanne muuttuu kriittiseksi, kun operointi ja Security asettavat tiukempia vaatimuksia, tarvitaan uusia rajapintoja tai Windows- ja verkko­päivitykset alkavat vaikuttaa tiedostokäyttöön ja lukituksiin.

Tämä kirjoitus jäsentää tyypillisiä lähtötilanteita ja osoittaa modernisointipolkuja, jotka kunnioittavat käynnissä olevaa käyttöä. Keskitymme vähemmän frameworkeihin tai lähdekoodin yksityiskohtiin ja enemmän hallinnointiin, dataan, rajapintoihin, ylläpitoon, turvallisuuteen ja migraation riskeihin kohdistuviin vaikutuksiin. Tavoitteena on toimintamalli, jonka IT-johto tai tekninen projektivastuuhenkilö voi suunnitella, ohjata ja perustella liiketoimintayksiköille.

Miksi Paradox-asennukset nykykäytössä horjuvat

Paradox ei teknisesti ole “rikki” tiedostopohjaisena tietokantateknologiana (taulukot tiedostoina), mutta se soveltuu yhä huonommin nykyaikaisiin operatiivisiin vaatimuksiin. Data sijaitsee usein jaetulla verkkolevyllä, käyttö tapahtuu työpöytäasiakkaiden kautta ja yhteyksiä hoitaa BDE tai muut ajurikerrokset. Tämä törmää nykyaikaisten vaatimusten kanssa saatavuudesta, jäljitettävyydestä ja kontrolloiduista muutoksista.

Tyypillisiä modernisoinnin ajureita ovat:

• Vakavuus verkkokäytössä: Tiedostopohjaiset lukitusmekanismit ovat herkkiä latenssille, offline-tilanteille, aggressiivisille virustorjunnan skannauksille tai epävakaille WLAN-yhteyksille. Tämä ei välttämättä näy suorana “kaatumisena”, vaan satunnaisina kirjoituskonflikteina, lukittuina tietueina tai vioittuneina indekseinä.
• Turvallisuus ja säädösten noudattaminen: Käyttö filesharessien ja paikallisten asennusten kautta hankaloittaa keskitettyä pääsynhallintaa. Tarkastuskelpoisuuden, muutosten jäljitettävyyden ja yhdenmukaisten oikeuksien varmistaminen on tiedostojärjestelmälogiikalla vaikeampaa kuin palvelintietokannassa.
• Rajapinnat ja integraatio: Kun tarvitaan DMS/ERP/CRM-liitäntöjä, REST-APIt (HTTP-pohjaiset ohjelmointirajapinnat) tai raportointi keskitetyistä datamalleista, tiedostopohjainen lähestymistapa muodostuu nopeasti pullonkaulaksi.
• Ylläpidettävyys ja tietämysriski: Monet Paradox/BDE-ratkaisut ovat kiinni harvojen henkilöiden tiedoissa, jotka tuntevat datayhteydet, taulujen ylläpidon ja virhetilanteet. Kun tämä tieto katoaa, operatiivinen epävarmuus kasvaa.
• Skaalaus ja samanaikaisuus: Enemmän käyttäjiä, enemmän toimipaikkoja, enemmän automaatiota – kaikki lisää samanaikaisten käyttöjen määrää. Juuri näissä tilanteissa tiedostopohjaiset tietokannat ovat käytännössä alttiimpia ongelmille.

Päätelmä: modernisointi on harvoin ”kaikki uusiksi” -projekti. Käytännössä toimiva polku hallitsee datariskejä ja siirtää toimialalogiikan vaiheittain luotettavaan arkkitehtuuriin.

Tilannekartoitus: mikä Paradox-variaatio on oikeasti käytössä?

”Meillä on Paradox” voi teknisesti tarkoittaa hyvin erilaisia asioita. Suunnittelussa on tärkeää, että järjestelmää ei nähdä vain tietokantana, vaan kokonaisuutena, joka koostuu datasta, käyttökerroksesta ja käyttöympäristöstä.

Tekniset osat, jotka tulee kartoittaa huolellisesti

• Tallennus- ja polkurakenne: Missä taulukot, indeksit ja väliaikaiset tiedostot sijaitsevat? Paikallisesti, fileservereillä, DFS-rakenteissa? Onko olemassa useita kopioita per toimipaikka?
• Käyttökerros: Käytetäänkö Borland BDE (historiallinen tietojen käyttökerros Delphi/C++-sovelluksille) vai vaihtoehtoisia ajureita? Onko ODBC-siltoja tai omatekoisia ratkaisuja?
• Asiakasympäristö: Mitkä Windows-versiot, Terminalserver/RDS, Citrix, paikalliset asennukset, sekavat oikeusmallit?
• Samanaikaiset yhteydet: Kuinka monta käyttäjää samanaikaisesti, mitkä erätyöt, mitkä automaattiset vienti-/tuontiprosessit?
• Taulukkologia: Viitteet, avainperiaatteet, „pehmeät“ suhteet ilman todellisia rajoitteita, historiallisesti muotoutuneet kenttätulkinnat.
• Integraatiot: Excel-viennit, CSV-tuonnit, DMS-arkistointi, massakirjeprosessit, ulkoiset järjestelmät, jotka käyttävät tiedostoja suoraan.

Tämä inventaario ei ole muodollisuus. Se ratkaisee, onko migraatio mahdollista muutamassa hallitussa vaiheessa vai täytyykö ensin vakauttaa tietojen laatu ja pääsytavat.

Modernisointitavoitteet: Mitä „valmis“ tarkoittaa ennen aloittamista

Monet projektit eivät kaadu tekniikkaan vaan epäselviin tavoitekuviin. „Pois Paradoxista“ ei ole tavoite vaan toive. Luotettavaa suunnittelua varten kannattaa täsmentää, mitkä ominaisuudet modernisoinnin jälkeen tulee täyttyä.

Pragmaattiset tavoitekriteerit käytölle ja IT-hallinnolle

• Keskeinen, transaktionaalinen tietoydin: Tietomuutokset kulkevat palvelintietokannan kautta käyttäen transaktioita (atomiset, konsistentit muutokset) ja määriteltyä lukituslogiikkaa.
• Selkeät käyttöoikeudet: Roolit, monivuokraisuus (tarpeen mukaan), pääsyjen ja muutosten lokitus.
• Varmuuskopiointi ja palautus määritellyin ajoituksin: Ei „kopioida jonnekin“, vaan palautustestit, RPO/RTO (tietojen menetyksen ja jälleenkäynnistyksen tavoitteet) ja määritellyt vastuut.
• Integraatio rajapintojen kautta: Sen sijaan, että ulkopuoliset prosessit käyvät tiedostoihin: määritellyt API:t tai tuonti-/vienti-prosessit validoinnilla.
• Julkaisun ja muutosten hallintaprosessi: Tietokantamigraatiot versionoituna, rollback-strategiat kuvattuina, testausympäristöt realistisina.

Mitä selkeämmät nämä kriteerit ovat, sitä helpompi on päätös, teettekö ensin „BDE-korvaus“ käyttökerroksessa vai siirryttekö suoraan asiakas-palvelin-migraatioon.

Paradox-tietokantojen modernisointi: Kolme vakiintunutta tavoitearkkitehtuuria

Käytännössä kolme tavoitekuvaa on vakiintunut. Mikä vaihtoehto sopii, riippuu tietomäärästä, integraation tasosta ja modernisointipaineesta. Tärkeää: Voitte myös yhdistellä vaihtoehtoja tai käyttää niitä väliaskelmina.

1) „Vakiinnuta ja irrota“: Käyttökerros modernisoidaan, tiedot säilytetään toistaiseksi

Jos liiketoimintayksikkö ei salli muutoksia ja käyttö toimii tällä hetkellä „niin ja näin“, ensimmäinen askel voi olla käyttökerroksen irrottaminen ja riskien vähentäminen. Usein siihen kuuluu BDE-Ablösung: Die BDE wird durch modernere Datenzugriffe ersetzt, um Betrieb auf aktuellen Windows-Versionen und in gehärteten Umgebungen besser kontrollieren zu können. Technisch wird dabei oft in Richtung BDE-Ablosung mit nativer Anbindung (Delphi-Datenzugriffskomponente mit Treibern und einheitlichem API) oder andere native Treiberschichten geplant, ohne den Fachprozess sofort umzubauen.

Tämä ei ole lopputila. Mutta se voi ostaa aikaa: vähemmän riippuvuutta vanhoista asennusrutiineista, parempi lokitus, selkeämpi konfiguraatio, usein myös parempi virheiden näkyvyys tuotannossa.

2) „Client-Server-Kern“: siirtymä SQL Serveriin tai PostgreSQL:ään

Yleisin kestävä ratkaisu on taulujen migraatio palvelintietokantaan, esimerkiksi Microsoft SQL Server tai PostgreSQL. Molemmat tarjoavat transaktionaalisen turvallisuuden, keskitetyt käyttöoikeudet, yhtenäiset indeksit, selkeät varmuuskopiointistrategiat ja paremmat integraatiomahdollisuudet. Yrityksille tämä merkitsee ennen kaikkea käyttöhyötyjä: monitorointi, replikaatio, selvät vastuut ja vähemmän riskiä tiedostopalvelimen aiheuttamien vaikutusten takia.

Tärkeää: Tietojen migraatio on vain puolet työstä. Vähintään yhtä oleellista on sovelluslogiikan mukauttaminen todellisiin transaktioihin, palvelinpuolen rajoitteisiin ja selkeämpään tietomalliin.

3) „Service-Schicht zuerst“: API ennen asiakasohjelmaa, vaiheittainen modernisointi

Jos useat sovellukset käyttävät Paradox-tietoja tai uusia portaaleja/automaatioita on suunnitteilla, palvelukerros voi olla ensimmäinen jäsentelevä askel. Tarkoitetaan keskitettyä REST-Service (HTTP-Schnittstelle), joka kapseloi luku- ja kirjoitusoperaatiot. Näin taulujen suora käsittely vähenee ja luodaan hallittu integraatiokerros. Tämä vaihtoehto on erityisen hyödyllinen, kun uusia web-portaaleja tai ulkoisia rajapintoja rakennetaan, samalla kun työpöytäasiakas säilyy vielä jonkin aikaa käytössä.

Tietokantamigraatio voi seurata tämän jälkeen ilman, että jokaista integraatiota tarvitsee käsitellä uudelleen.

Tietomigraatio: Tiedostopohjaisesta relaatiotietokantaan – tyypilliset kompastuskivet

Paradox-tietokannat ovat usein „fachlich korrekt“, mutta teknisesti epäjohdonmukaisia. Siirryttäessä relaatiopohjaiseen palvelintietokantaan tämä epäjohdonmukaisuus paljastuu. Joka aliarvioi tämän, aiheuttaa muutoksen jälkeen tukitapauksia, koska listat lajitellaan eri tavalla, duplikaatteja ilmestyy tai raportit poikkeavat äkillisesti.

1) Schlüssel, Dubletten und „historisch erlaubte“ Unschärfen

Monissa Paradox-järjestelmissä ei ole selkeitä primääriavaimia tai niitä ei ole käytetty johdonmukaisesti. SQL Serverissä/PostgreSQL:ssä yksiselitteiset avaimet ovat kuitenkin keskeisiä: suorituskyvyn, viitteiden ja tietojen eheyden kannalta. Tyypillisiä tehtäviä:

• Dublettien tunnistaminen näennäisesti yksiselitteisissä kentissä (esim. asiakas- tai tositenumerot).
• Primääriavaimien määrittely (luonnolliset vs. tekniset ID:t) ja vanhojen tietojen käsittely.
• Vierasavaimien (Beziehungsregeln) käyttöönotto siellä, missä se on toiminnallisesti perusteltua – tai tietoinen luopuminen ja korvauslogiikka.

Tämä on vähemmän „Datenbanktheorie“ kuin käyttörealiteetti: Ilman selkeitä avaimia myöhemmät rajapinnat, synkronoinnit ja auditoinnit muuttuvat kalliiksi.

2) Zeichensätze, Sonderzeichen und Sortierung

Gerade bei älteren Installationen sind Zeichensätze und Sortierregeln historisch gewachsen. Nach der Migration kann sich die Sortierung (Collation) ändern: Umlaute, ß, Groß-/Kleinschreibung oder Akzentzeichen verhalten sich anders. Für Anwender wirkt das wie ein Fehler, obwohl die Daten korrekt sind. Planen Sie daher:

• Määrittäkää yhdenmukainen collation kohdetietokantaan.
• Yhdenmukaistakaa hakulogiikat (tarkka vs. case-insensitive).
• Testit todellisilla tiedoilla, ei pelkästään demo-datenseteillä.

3) Datums- und Zahlenformate, Rundung, leere Werte

Tiedostopohjaiset järjestelmät sietävät usein arvoja, jotka eivät suoraan sovi palvelintietokantaan: tyhjät päivämääräkentät, numerot tekstinä, sekoitetut desimaalierottimet. Migratiossa tarvitsette muunnossäännöt ja selkeän strategian sille, mitä „tuntematon“ tarkoittaa (NULL, 0, tyhjä merkkijono). Tämä on ammatillisesti merkittävää, koska se vaikuttaa raportointiin ja jatkoprosesseihin.

4) Sperren und Nebenläufigkeit: Verhalten ändert sich

Paradox-lukitus ja palvelintietokannan transaktiot toimivat eri tavoin. Palvelintietokannassa on selkeästi määritellyt Isolation Levels (säännöt siitä, miten samanaikaiset käyttöyritykset näkevät toistensa muutokset). Tämä vaikuttaa mm.:

• perustietojen samanaikaiseen muokkaukseen,
• eräajoihin (esim. erälaskutus),
• pitkiin transaktioihin, joita aiheuttavat asiakasohjelman „auki“ olevat lomakkeet.

Tämä ei ole syy vastustaa migraatiota – mutta se on peruste keskustella varhaisessa vaiheessa liiketoimintayksiköiden kanssa käyttöohjeista, lukituskonsepteista ja konflikti-ilmoituksista.

Parallelbetrieb statt Big Bang: Risiko kontrolliert reduzieren

Yritysympäristöissä muutos „yhteen viikonloppuun“ tehtynä on harvoin realistinen. Ein Parallelbetrieb vähentää riskiä, kun se suunnitellaan huolellisesti. Tavoitteena ei ole pitää kahta maailmaa pysyvästi käynnissä, vaan siirtymävaihe selkeillä säännöillä.

Praktikable Muster für Parallelbetrieb

• Read-only Spiegel: Uutta tietokantaa täytetään Paradoxista ja käytetään raportointiin/BI:hin. Kirjoitusoperaatiot jäävät aluksi vanhaan järjestelmään. Tämä on hyvä tapa validoida tietojen laatu, kenttämappaus ja suorituskyky.
• Write-through über eine Schicht: Kirjoitusoperaatiot kulkevat keskitetyn logiikan kautta, joka palvelee sekä Paradoxia että kohdetietokantaa. Tämä on vaativampaa, mutta voi vähentää riippuvuuksia.
• Modulweise Umschaltung: Tietyt prosessit (esim. tilauksen luonti) siirtyvät ensin, muut seuraavat. Ehtona ovat selkeät rajapinnat moduulien välillä ja vakaa datan omistajuus kutakin prosessia varten.

Tärkeää on yksiselitteinen „System of Record“ kunkin datan alueen osalta: on oltava selvää, mikä tietolähde on johtava. Muuten syntyy poikkeamia, jotka joudutte myöhemmin työläästi korjaamaan.

Rollback, Backups und Nachvollziehbarkeit: Was IT-Betrieb wirklich braucht

Modernisointi hyväksytään tuotannossa vasta, kun poikkeamapolut ovat selkeät. Tähän kuuluvat eivät ainoastaan varmuuskopiot, vaan myös jäljitettävät muutokset tietoihin ja skeemaan.

Minimalanforderungen, die Sie vor dem Cutover definieren sollten

• Wiederherstellungsplan: Kuka tekee mitä, missä järjestyksessä ja millä käyttöoikeuksilla? Ein RESTore on prosessi, ei ominaisuus.
• Test der Wiederherstellung: Ei teoreettisesti, vaan staging-ympäristössä realistisilla tietotasoilla.
• Schema-Versionierung: Tietokantamuutokset versionoidaan ja otetaan käyttöön toistettavasti. Tämä vähentää yllätyksiä hotfixeissä.

Erityisesti Paradoxin vanhoissa järjestelmissä „jäljittävyys“ ratkaistaan usein implisiittisesti tiedostojen, varmuuskopioiden ja kokemusperäisen tiedon avulla. Modernissa ympäristössä sen tulisi olla eksplisiittistä.

Rajapintojen modernisointi: pois tiedostokäytöstä, kohti hallittuja virtoja

Monet riskit Paradox-ympäristöissä eivät synny ydinjärjestelmässä vaan „sivuprosesseissa“: Excel-makrot, tuonnit ulkoisista järjestelmistä, eräajot, jotka käsittelevät tauluja suoraan. Migraation aikana nämä pääsyt täytyy tunnistaa ja korvata.

Mitä integraatioissa tulisi järjestelmällisesti selvittää

• Mitä järjestelmiä todella luetaan/kirjoitetaan? Ei vain virallisesti, vaan myös „epävirallisissa“ yksiköissä.
• Mitkä datavirrat ovat kriittisiä? Esimerkiksi perustiedot vs. tositteet vs. tilatiedot.
• Mitkä validoinnit puuttuvat nykyään? Tiedostopohjaiset tuonnit ohittavat usein järkevyystarkistuksia, jotka myöhemmin johtavat dataroskaan.
• Kuinka virheenkäsittely hoidetaan? Nykyaikaiset rajapinnat tarvitsevat kuittaukset, uudelleenyritykset ja selkeät virheilmoitukset.

Hyvä tavoitetila on API- tai palvelukerros, joka keskittää tietokäytöt. Tämä on myös tietoturvan kannalta olennaista: sen sijaan, että käytetään suoria jakelupääsyjä ja hajautettuja tunnuksia, työskentelette keskitettyjen identiteettien ja lokitettujen pyyntöjen kanssa.

Tekninen migraatiosuunnittelu: käytännössä toimiva lähestymistapa

Liiketoimintaohjelmistoja ei voi migroida kuten laboratorioprojektia. Tarvitsette lähestymistavan, joka yhdistää toiminnallisen hyväksynnän, käyttövalmistelun ja teknisen toteutuksen.

Käytännössä toimiva kuuden vaiheen prosessi

1. Kartoitus ja riskiarviointi: tietolähteet, pääsyt, riippuvuudet, kriittiset prosessit, käyttökonsepti.
2. Tavoitetila ja migraation rajapinta: Mitkä tietokokonaisuudet siirtyvät ensin, mitkä jäävät toistaiseksi? Johtavan tietolähteen määrittely.
3. Tietomalli ja mapping: taulut, avaimet, tietotyypit, muunnossäännöt, historisointi.
4. Tekninen koekäyttö: migraatio staging-ympäristössä, suorituskykytestit, raporttien ja ydintoimintojen vertailu.
5. Rinnakkaiskäyttö mittauspistein: lokitus, virheluokat, tietojen vertailu, määritellyt keskeytyskriteerit.
6. Cutover ja stabilointi: siirtymä, monitorointi, jatkotyöt, vanhojen pääsyjen poiskytkentä, dokumentaatio käyttöä varten.

Tämä lähestymistapa on tarkoituksellisesti iteratiivinen: mitä aikaisemmin testaatte todellisia tietoja ja prosesseja, sitä pienempi riski, että „viimeiset 10 %“ räjähtävät.

Työkalut ja käyttö: monitorointi, suorituskyky ja oikeuskonsepti alusta alkaen

Yleinen virhe on käsitellä uutta palvelintietokantaa kuin „parempaa tiedostovarastoa“. Palvelintietokannat tarvitsevat käyttökonsepteja: monitorointi, kapasiteettisuunnittelu, indeksien ylläpito, käyttöoikeuksien hallinta. Tämä ei ole ylimääräistä työtä, vaan estää tyypilliset „kolmen kuukauden jälkeen hidastuu“ -efektit.

Konkreettiset käyttökohtaiset tekijät, jotka tulisi suunnitella

• Monitorointi: yhteysmäärät, hitaat kyselyt, lukituskonfliktit, muisti- ja I/O-kuorma.
• Indeksien ja statistiikan ylläpito: vakaan suorituskyvyn varmistamiseksi kasvavissa tietomäärissä.
• Oikeudet ja roolit: minimioikeudet, luku-/kirjoitusroolien eriyttäminen, hallinnollisten pääsyjen dokumentointi.

IT‑Johto ja järjestelmänvalvojat hyötyvät tästä usein eniten: vaikeasti selitettävien tiedostopalvelinongelmien sijaan on käytettävissä mitattavia mittareita ja standardoituja käyttöprosesseja.

Mitä ehdottomasti tulee välttää

Tietyt toimintamallit toistuvat modernisointiprojekteissa – ne syövät aikaa, rahaa ja luottamusta. Kolme seikkaa ovat erityisen olennaisia:

• Migraatio ilman datalaadun tarkistusta: Jos duplikaatit ja erikoistapaukset havaitaan vasta siirron jälkeen, kuorma päätyy tukeen ja toimialueelle. Parempi: tuottaa varhaisessa vaiheessa datalaaturaportit ja arvioida ne yhdessä.
• Vanhojen pääsyjen liian varhainen sammuttaminen ilman suunnitelmaa: Monet ”pienet” prosessit lukevat suoraan tauluista. Jos nämä puuttuvat maanantaina, syntyy kaaos. Tunnistakaa sivuprosessit ja järjestäkää korvaavat reitit.
• Epäselvät vastuut tuotannon ja projektin välillä: Kuka tekee päätökset suorituskykyongelmissa? Kuka saa ottaa skeemamuutokset käyttöön? Määritelkää vastuut ennen ensimmäistä tuotantokäyttöön siirtoa.

Luokittelu Delphi/BDE-kannoille: Modernisointi ilman täydellistä uudelleenkirjoitusta

Monet Paradox‑asennukset perustuvat Delphi‑työpöytäsovelluksiin. Tärkeää on ymmärtää: modernisointi ei automaattisesti tarkoita uudelleenkirjoittamista. Usein asteittainen uudelleenrakentaminen on kestävä ratkaisu, kun arkkitehtuuri ja tietojen käyttö on selkeästi erotettu. Selkeä kerrostus (esim. Layer-3‑arkkitehtuuri: käyttöliittymä, liiketoimintalogiikka, tietojen käyttö) auttaa toteuttamaan tietokantamigraation kontrolloidusti ilman, että koko järjestelmää tarvitsee koskea kerralla.

Jos BDE‑korvaus on ajankohtainen, kannattaa myös tarkastella keskitettyä konfiguroitavuutta, lokitusta ja ohjainstrategiaa, jotta uudet tietokannat (SQL Server, PostgreSQL) voidaan ajaa jokaisella asiakkaalla ilman „Sonderinstallationen“.

Yhteenveto: Modernisointi on käyttöprojekti – tiedot ovat ytimessä

Paradox‑järjestelmät ovat usein kestäviä, koska ne mallintavat prosesseja luotettavasti. Tätä ammatillista vakautta tulee suojella. Onnistunut modernisointi ei keskity vain „teknologian korvaamiseen“, vaan kontrolloituun datanhallintaan, puhtaisiin integraatioihin ja käyttöön, joka on mitattavissa, palautettavissa ja turvallinen. Käytännöllinen tie kulkee selkeän nykytilakartoituksen, tavoitenäkymän käyttövaatimuksineen, migraation datalaatusääntöineen ja tarvittaessa rinnakkaiskäytön kautta määritellyllä rollbackilla.

Jos haluatte arvioida lähtötilanteenne (tiedot, käyttöoikeudet, BDE/Delphi‑riippuvuudet, integraatiot) jäsennellysti, lyhyt tekninen esikeskustelu on usein nopein tapa selventää riskejä ja järkeviä migraatiokohteita: ota yhteyttä.

Ammattikontekstissa Paradox‑tietokantamigraatio ja Borland BDE‑korvaus ovat myös keskeisiä, kun integraatioiden, tietovirtojen ja jatkokehityksen on toimittava saumattomasti yhdessä.

Keskustele projektista tai modernisointihankkeesta Net-Base kanssa.