M.i.v. deze Releasenote is Profit-Change-Key (Sleutelwijzigingen) v.w.b. de ADS versie zodanig aangepast dat deze de sleutelwijzigingen kan uitvoeren m.b.t. SQL opdrachten.
SQL (ADS) bepaalt vervolgens welke index het beste kan worden gebruikt om de sleutelwijzigingsopdracht uit te kunnen voeren; Profit kan volstaan met het geven van 1 SQL opdracht om de gevraagde sleutels om te nummeren. Het omnummeren gaat hierdoor een stuk sneller.
Merk op dat zodra Sleutelwijzigingen via een SQL statement verlopen, de Server 1 opdracht krijgt om alle sleutels in een tabel te wijzigen. Hierdoor krijgt Profit niet de mogelijkheid om voor ieder record een 'Transaktie' te registeren.
Nu is het transaktioneel definieren van een tabel in ADS in principe helemaal niet eens nodig, immers, de ADS Database kan zelf gewoon met SQL commando's benaderd worden. Met Profit-Transakt konden we een tabel transaktioneel maken, waarna de tabel repliceerd werd naar een SQL Server. Op die manier was er een (separate) SQL Database met daarin een kopie van de gegevens die in de VFP database stond. Deze SQL Database kon dan vervolgens voor talloze SQL Queries worden gebruikt.
Een Advantage Database Server tabel kan al met SQL worden benaderd, en daarmee vervalt het nut om deze database nog eens naar een andere SQL database te repliceren. Indien er echter toch gerepliceerd wordt naar een separate SQL Server (bijvoorbeeld omdat er voor de oude situatie allerlei Queries ontwikkeld zijn die nog niet zijn omgebouwd naar de ADS Server variant) dan geldt dat Profit de tabellen die als "transaktioneel" gedefinieerd zijn niet zal omnummeren middels een SQL Query. In die situatie zal er gewoon op de oude wijze, d.w.z. record voor record (waar mogelijk volgens index) worden omgenummerd.
In theorie zouden we nog kunnen stellen dat omnummeren via een SQL Query best in toegestaan als een tabel transaktioneel is, mits de tabel daarna maar opnieuw wordt geupload naar de SQL Server. De ervaring leert dat de kans heel erg groot is dat de gebruikers dit nalaten, waarna er allerlei ellende kan ontstaan. En, wetende dat er tabellen zijn die inmiddels tientallen GB groot zijn, is het niet voor de hand liggend dat na het omnummeren van 1 Debiteur we 'even' 20 GB aan data opnieuw gaan uploaden naar een SQL Server.
Indien een tabel transaktioneel is, maar transaktie verwerking in het aktieve bedrijf is uitgeschakeld, dan kan er alsnog gebruik worden gemaakt van het omnummeren m.b.v. een ADS SQL Query; immers, Transakties worden dan toch niet gemaakt.
Indien U wel bereid bent om een tabel opnieuw te uploaden naar ADS, dan zou een truc kunnen zijn het bedrijf even niet transaktioneel te definieren, dan om te nummeren, en daarna de hele tabel opnieuw te repliceren naar de separate SQL database.
Een bestand wordt in ADS alleen o.b.v. SQL omgenummerd indien aan onderstaande voorwaarden wordt voldaan:
* Tabel dient zelf als ADS tabel te zijn gedefinieerd
* Alle bijbehorende 'Tekst' tabellen moeten eveneens als ADS tabel gedefinieerd zijn
* De Tabel mag niet transaktioneel zijn, tenzij het bedrijf niet transaktioneel is.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APCKDO | Omschrijving (nog) niet bekend | 24-04-2015 | 28-04-2015 |
| APCKDO1 | Omschrijving (nog) niet bekend | 24-04-2015 | 06-05-2015 |
| APCKDO2 | Omschrijving (nog) niet bekend | 17-03-2015 | 30-04-2015 |
| APCKDO4 | Omschrijving (nog) niet bekend | - - | 07-05-2015 |
| APTD | Omschrijving (nog) niet bekend | 03-12-2014 | 07-05-2015 |
| LOINTV | Omschrijving (nog) niet bekend | 10-03-2015 | 29-04-2015 |
| SYCKTV | Toevoegen Sleutelwijzigingen | 29-04-2015 | 30-04-2015 |
| SYCLRA | Logboek Sleutelwijzigingen | 29-04-2015 | 29-04-2015 |
