(DEV)
Programma’s waarbij je een database gebruikt, worden dikwijls ontwikkeld op een andere databank dan diegene die uiteindelijk zal gebruikt worden.
Stel dat de ontwikkeling gebeurt op server (DEV), met databank employee. Die server kan evengoed een virtuele machine, je eigen desktop of laptop zijn.

Structuur (DEV) –> (PRODUCTION)
Op een bepaald moment wordt het programma in gebruik genomen, en maak je dus een definitieve databank aan op de server (PRODUCTION), die werkelijk gebruikt wordt. Waarschijnlijk houd je je DEV voor verdere ontwikkeling, met een kleine test-database met relevante gegevens voor wat je aan het ontwikkelen bent, terwijl die van de (PRODUCTION) server met rasse schreden in volume toeneemt.

Data (PRODUCTION) –> (TEST)
Die verdere ontwikkeling testen met echte productie data wil je misschien laten doen door iemand anders, terwijl jij voortontwikkelt. Dan is het handig om een (TEST) systeem te hebben. De data kan je uit de productieserver halen, zodat je op grote aantallen data kan testen, wat realistischer is.

(DEV) ? (TEST) ? (PRODUCTION)
Als je nu vanop je ontwikkelomgeving programma’s wil gebruiken met data van TEST (vers geupdate van PRODUCTION), moet je de gegevens van je verbinding met de databank in het programma aanpassen. Waarschijnlijk in een settings- of configuratiebestand, wat het iets gemakkelijker maakt. Je kan dat settingsbestand dan in versies DEV en TEST maken, en met een shell script het te gebruiken configuratiebestand kopiëren over het standaard configuratiebestand. Of kan het vanuit je software?

Dataset
Concept: je kan in je programma voorzien om verschillende datasets te gebruiken. Gevolg is dat je in een menu kan omschakelen naar “dev”, “test”, of “production”, en dat de juiste connectiegegevens geladen worden.

Ik gebruik een aparte module voor de data (1)
MData

Ik nummer mijn datasets, zodat ik ze gemakkelijk kan aflopen maar ook in de Settings kan opslaan: 0, 1, 2…
Ik houd in een variabele in de data module bij welke dataset momenteel in gebruik is:
PRIVATE iCurrentDataSet AS Integer

Ik geef de dataset een standaard naam in de module die de data gebruikt:
PRIVATE CONST sDataSetName = "dbdata"

Voor de eigen data heb ik dus db configuraties:
dbdata0, dbdata1, dbdata2 (0-dev, 1-test, 2-production).

In de Settings file komt bv:
[dbdata0]
servertype="mysql"
datasetname="dbdatadev"
database="maindb"
host="localhost"
login="myapp"
password="ldfjq5sehrqz"
...
[dbdata1]
servertype="mysql"
datasetname="dbdatatest"
database="maindb"
host="test.copyleft.loc"
login="myapp"
password="ldfjq5sehrqz"
...

Om de instelling van de juiste dataset “sDataset” op te halen, te bewaren moet je hem natuurlijk kunnen benoemen:

Settings["dbdata1/host"]

Of via universelere code
sDataset & "/host"
waarbij
sDataset = getDataSetString(iCurrentDataSet)

Die is samengesteld van de naam plus het nummer, een procedure uit de betreffende module levert die:

PUBLIC SUB getDataSetString(i as Integer) AS String
   RETURN sDataSetName & Str$(iCurrentDataSet)
END

Hiermee kan je de voorkeuzelijst vullen.

Als je meer data modules gebruikt:

Een aparte module voor de data, import, export, enz, met telkens hetzelfde systeem.
MData
MImport
MExport

krijgt in elke module de dataset een *andere* naam:

dbdata = voor de eigen data van het programma
dbimport = voor data die geïmporteerd wordt uit een andere databank
..

Voor de import data heb ik dan datasets:
dbimport0, dbimport1, dbimport2

In de settingsfile zijn die dan terug te vinden:

[dbimport0]
servertype="mysql"
datasetname="dbimportdev"
database="maindb"
host="localhost"
login="readimport"
password="ldfjq5sehrqz"
...
[dbimport1]
servertype="mysql"
datasetname="dbimporttest"
database="maindb"
host="test.copyleft.loc"
login="readimport"
password="ldfjq5sehrqz"
...

Een aanzet tot ietwat universele code:

PUBLIC CONST sDataSet AS String = "dbimport" ' <---- Change this
' to change for each module - base for name in settings file

PRIVATE iCurrentDataSet AS Integer = 0 ' no of dataset, 0 is default, alternatives 1, 2, .. defined in settings

PRIVATE sCurDataSetName AS String ' 

PUBLIC $hconData AS NEW Connection



PUBLIC SUB getLastError() AS String
  
  RETURN sLastError
  
END

PUBLIC SUB resetError()
  
  sLastError = ""
  
END


PUBLIC SUB curDataSetString() AS String
  
  RETURN getDataSetString(iCurrentDataSet)
  
END

PRIVATE SUB getDataSetString(i AS Integer) AS String
  
  RETURN sDataSet & Str$(iCurrentDataSet)
  
END

PUBLIC SUB getDataSetName() AS String
  
  RETURN sCurDataSetName
  
END


PUBLIC SUB loadDataSet(iDataSet AS Integer) AS Boolean
  
  DIM sData AS String
  
  iCurrentDataSet = iDataSet
  sData = getDataSetString(iCurrentDataSet)
  
  DEBUG Settings.Path &/ Application.Name & ".conf"
  IF (Exist(Settings.Path &/ Application.Name & ".conf"))
    sCurDataSetName = Settings[sData & "/datasetname"]
    WITH $hconData
      .Host = Settings[sData & "/host"]
      .Name = Settings[sData & "/database"]
      .Login = Settings[sData & "/login"]
      .Password = Settings[sData & "/password"]
      .Type = Settings[sData & "/servertype"]
    END WITH 
    RETURN TRUE
  ELSE 
    iCurrentDataSet = -1
    sLastError = "Could not find data connection settings " & Error.Text
    RETURN FALSE
  ENDIF   
  
END


PUBLIC SUB goConnect() AS Boolean
  
  TRY $hconData.Close
  TRY $hconData.Open
  IF ERROR 
    sLastError = Error.Text
    RETURN FALSE
  ELSE 
    RETURN TRUE
  ENDIF 
  
END

Naar aanleiding van een vroeger artikel over hergebruik van code, kwam ik op de kwestie van de standaardisering van de veldnamen in een databank. Algemeen zie ik twee systemen gebruikt worden:

1. Met prefix:

Meestal een korte prefix die de naam van de tabel aangeeft, zodat je altijd kan zien waar de veldnaam op slaat:

Inderdaad de employee tabel, “emp” of beter “employee”.

2. Zonder prefix

Zonder tabelnaam (afkorting) in veldnamen:

In dit geval moet je de (afkorting voor) de veldnaam niet meegeven. Als de database vermeld wordt is het toch duidelijk:

emp.id
employee.name
employee.fieldname1
employee.creat
employee.creby
employee.updat
employee.updby

eventueel met korte alias

emp.id
emp.name
emp.fieldname1
emp.creat
emp.creby
emp.updat
emp.updby

Veel code blijft korter, maar een luie blik op de resultaten van een query kan iets meer aandacht gaan vragen (om de oorspronkelijke tabelnaam te zoeken), en misschien worden je aliassen langer e.veld wordt emp.veld voor table employee.

Vgl:

e.emp_id, e.emp_name
emp.id, emp.name

De prefix blijkt vooral een overblijfsel te zijn van vroeger, toen alle veldnamen uniek moesten zijn (ook buiten de tabel).

De algemene raadgeving is: geen prefix gebruiken:

• korter
• eenduidiger
• goede tabelnamen en aliassen te gebruiken
• betere standaardisatie

Pro prefix:

• oude systemen waar het moet
• geen probleem met gereserveerde woorden (commanodo’s in de query taal)*
• gemakkelijk bij export want tabelnaam staat in veld.
• soms beter leesbaar omdat velden altijd dezelfde vorm hebben.

* stel dat je een veld hebt waarin je aangeeft dat er een update gebeurd is of moet gebeuren:
employee.update
Helaas, UPDATE is een gereserveerd woord in de SQL taal (SELECT update FROM …), en zo zijn er nog woorden die door de syntax highlighting kunnen aangewezen worden als “gereserveerd”. Door prefixen te gebruiken moet je daar nooit op letten. Maar je kan ook ‘quotes’ gebruiken rond het gereserveerd woord als veldnaam.

Zie ook discussie op StockOverflow: (1) en (2)

Na het vervangen van een server treden er eigenaardige fouten op, die te maken hebben met tijdsberekening. Nader onderzoek leidt me tot enkele eenvoudige testen:

Gambas commandolijn (onderaan in de IDE):

? week(now())

41

Dan op de mysql server via de browser in phpmyadmin of rechtstreeks in de mysql commandprompt:

SELECT WEEK(NOW());

+-------------+
| week(now()) |
+-------------+
|          40 |
+-------------+
1 row in set (0.02 sec)

Niet iedereen begint op dezelfde manier te tellen; de Europeanen blijkbaar vanaf de eerste dag van het jaar, de Amerikanen vanaf de eerste volle week van het jaar.

In het voorbeeld Database (voorbeelden inbegrepen in Gambas) wordt zo informatie doorgegeven naar een opgeroepen form:

' Gambas class file

PRIVATE $hConn AS Connection

'......

PUBLIC SUB btnRun_Click()

  DIM rData AS Result
  DIM hForm AS FRequest

  rData = $hConn.Exec(txtRequest.Text)
  hForm = NEW FRequest($hConn, rData)
  hForm.Show

CATCH

  Message.Error(DConv(Error.Text))

END

De regel
hForm = NEW FRequest($hConn, rData)
geeft een Connection en een Result object mee.

Die worden opgevangen in de _new method van de aangeroepen form:

' Gambas class file

PRIVATE $hConn AS Connection
PRIVATE $rData AS Result
'....

PUBLIC SUB _new(hConn AS Connection, rData AS Result)

  $hConn = hConn
  $rData = rData

' ...

END

en omgezet in eigen variabelen (de $hConn is twee keer PRIVATE).

Kan misschien ook/anders door een aparte ModCommon te maken en daarin PUBLIC te declareren.

MySQL is even in de aandacht geweest wegens de aankoop van het moederbedrijf
MySQL AB door Sun. Hopelijk blijft het de basis van vele handige vrije software projecten.

Vanuit verschillende toepassingen kan je MySQL databank ondervragen met SQL statements.
Meestal is het handig om ze op voorhand uit te proberen.
Daarom: opslaan in een bestand, en het bestand laten uitvoeren.

Begin het bestand bv met het openen van de database:

USE mijngegevens_db;
SELECT * FROM mijntabel WHERE afdeling = "afd1";

Bewaar in een tekstbestand getMyData.sql

Vanop de mysql command prompt:
source getMyData.sql

Wil je de resultaten niet alleen over het scherm zien rollen maar ook nadien ergens terugvinden, doe dan op de mysql command prompt een “tee” alvorens de vraag te laten uitvoeren:

tee mysqlresultaat.txt
source getMyData.sql


In het tekstbestand mysqlresultaat.txt vind je het commando terug en het resultaat eronder.

Als je een aantal sql-vragen moet stellen met steeds een klein verschil in de vraag, bv telkens een andere maand, afdeling, .. kan je de sql-vraag in een tekstbestand plakken, kopieren naar het aantal totale vragen, en het ene stukje veranderen dat nodig is.

USE mijngegevens_db;
SELECT * FROM mijntabel WHERE afdeling = "afd1";
SELECT * FROM mijntabel WHERE afdeling = "afd2";
SELECT * FROM mijntabel WHERE afdeling = "afd3";


(Daar kan OOo Calc ook mee helpen; vult waarden aan bij kopieren).

Je kan dan de hele set sql-vragen tegelijk laten uitvoeren.

Telkens je iets doet wordt het bijgeschreven in het resultatenbestand.
Dat kan handig zijn omdat je zo een log hebt. Je kan het inderdaad
ook gebruiken terwijl je op de mysql command prompt werkt, om de resultaten nadien te bekijken, of de sql vragen te hergebruiken.

In bovenstaand kan je de verschillende bestaande afdelingen vinden met:

SELECT DISTINCT afdeling FROM mijntabel

die je dan weer zou kunnen gebruiken in een sql statement …