VaxNt na straně serveru i na straně klientského interpreteru může komunikovat přímo s jakoukoli běžně používanou databází, v úvahu připadá typicky ORACLE, MySQL, Interbase, SyBase apod. Zde popisovaný formát slouží k výměně off-line resp. při komunikaci vedoucí k periodické synchronizaci s heterogenním systémem.
Nativní formát výměny dat je zvolen tak, aby byl co možná nejobecnější a nevyžadoval žádné zvláštní nároky na partnerský systém, se kterým se data vyměňují. Předmětem výměny mohou být obsahy databázových tabulek a obecněji libovolných queries. Vedle toho je možno vyměňovat soubory - skutečné nebo dumpy BLOBů. Zde se soustředíme na první případ, tedy výměnu dat odpovídajících výsledku query. Jednotlivé záznamy / řádky query se transformují na textový soubor podle těchto zásad:

Oddělovači řádků jsou buď znaky CR a LF nebo LF. Obojí je přípustné a odpovídá to konvencím světa Windows resp. unixu.
Kódování češtiny je Win1250 - je to praktický ústupek tomu, že partnerské systémy jsou začastě určeny pro Windows.
Collation sequence pro třídění je pxw_csy, tedy třídění podle české normy, hodnoty '' a NULL se třídí nakonec. Collation sequence má význam jenom pro stringové položky.
Každý záznam je transformován na sadu rovnic tvaru JmenoPolozky=HodnotaPolozky. Obsahuje-li záznam tedy X položek, transformuje se na X řádků / rovnic ve výstupním souboru.
Jednotlivé záznamy jsou odděleny řádkem obsahujícím pouze znak '.'.
Případné řídící znaky jsou v hodnotách na pravé straně rovnic zakódovány podle běžných konvencí unixu resp. jazyka C. Tedy LF jako \n, CR jako \r atd.
Pořadí rovnic reprezentujících jeden záznam je libovolné. U jmen položek se nerozlišují velká a malá písmena.
Je-li hodnota některé položky '' nebo NULL, není nutno odpovídající rovnici uvádět. Rovnice tvaru "X=" s prázdnou pravou stranou se interpretuje tak, že se do X dosazuje ''. Tento subtilní rozdíl je významný jenom tam, kde aplikace opravdu rozlišuje mezi '' a NULL, tedy mezi hodnotou úmyslně prázdnou a hodnotu nevyplněnou.
Literál NULL se na pravé straně rovnice chápe opravdu jako NULL v databázovém smyslu. Je tedy prakticky jedno, zda exportní záznam obsahuje "X=NULL" nebo "X=" nebo žádný řádek pro proměnnou X.
Řádky obsahující na první pozici znak # se ignorují jakožto poznámky.
O rozsahu a ani typu dat na pravých stranách rovnic se neanticipuje nic. Formálně to jsou všechno stringy a je na importujícím či exportujícím systému, aby data správně chápal. Pro zápisy čísel se používají právě platné locales na straně exportujícího systému. VaxNt si speciálně v případě čísel poradí správně s desetinnou tečkou i čárkou.
Příklad formátu pro banální query "select Prijmeni,Jmeno,Titul,Poznamka from Personal order by 1". Úmyslně jsou uvedeny všechny nestandardní situace.

      Prijmeni=Nowak
      Jmeno=Petr
      Poznamka=Tento záznam má v sobě zlom řádku právě zde\n a ilustruje, že se mohou takto snadno vyměňovat i BLOBy ...
      # tento řádek se ignoruje - je to místo pro poznámky a případnou výměnu metadat mimo rámec formátu
      .
      Prijmeni=Průšová
      JMENO=Eva
      Titul=Ing.
      .
	

Dumpy tabulek a queries jsou přehledné a vznikající data se snadno vizuálně kontrolují. Pomocí běžných utilit jako je sed, awk, cut, grep, ... se dají tato data snadno transformovat na jakýkoli cílový formát.
Nadbytečná entropie - tedy důsledné pojmenování položek v každém záznamu - je kompenzována úsporností při vynechání nevyplněných položek a uváděním dat pouze ve skutečné délce. Soubory typu .equ jsou typicky velmi dobře komprimovány gzipem.
Struktura dat je typická pro streamy a VaxNt pochopitelně stejný formát používá i pokud je součástí tzv. pipe. To je hlavně důležité tam, kde je partnerským systémem nekonečný jednosměrný zdroj streamu, například technologicý systém, čidlo apod.
Do záznamů je možno snadno vkládat libovolně nové položky.
Záznamy mohou obsahovat i nadbytečná data, importující systém si bere jenom to, co jej zajímá.
Data položek mohou obsahovat i "divoké" znaky, tedy CR, LF apod.
Je možno snadno předávat obsah BLOBů - ve formě dlouhých řádků.
Formát je důvěrně znám jak programátorům v Perlu, tak i v Delphi. V obou prostředích jsou k dospozici efektivní prostředky a obraty na práci se sériemi rovnic. V prvním případě to jsou tzv. hashe, ve druhém např objekty typu TStringList.
Formát neanticipuje žádnou vnitřní reprezentaci a ani typy dat. To je hlavně důležité tam, kde různé databázové systémy mají neslučitelné chápání položek typu DATE apod. Unifikací na stringový zápis se vše řeší.
Konverzí na ASCII se rovněž zcela řeší neslučitelnosti při reprezentaci čísel, ale i položek typu MONEY apod.

Právě zde popsaný formát je ten, který produkuje klientský interpret a rovněž jej produkuje generátor sestav pro každou generovanou sestavu. Pro jistotu produkuje i méně obecný formát CSV. Znamená to tedy, že při každém generování jakékoli sestavy se na smluveném místě (typicky C:/tmp) objeví i datový ekvivalent sestavy ve formátech .equ a .csv.
Exportní a importní soubory se typicky pojmenovávají podle tabulek / queries a s příponou .equ.