Alventis offers you a facility to easily exchange data in Alventis' proprietary format with other Alventis users. You can also use this same functionality as means of creating selective data backups or "snapshots".


An InfoSet is a data table plus the InfoView forms that are based on it. Very simple. For the Contacts table, for example, this would be the Contacts table itself + whatever InfoView(s) may be "attached" to it.


To save and/or share something you have in Alventis with the rest of the world (or with a backup diskette, or whatever the reason may be), you can export any of the following:

The data table per se. This is a minimum. You can export the table with or without data, i.e., just the table structure (what fields it has, what their properties are, etc.) or the actual data as well.
The accompanying InfoView forms, if any. This is optional.

Whatever you end up exporting, we will refer to it as InfoSet (even if there are no InfoViews that come with it).


The basic concept is quite simple. Exporting an InfoSet saves a group of files relevant to what you choose to export. Importing an InfoSet imports it from such a group of files into some Alventis Database. Let's start by examining InfoSet Export.



BarIfxInfosetExport InfoSet Export is performed by clicking the Export InfoSet button. This launches the InfoSet Export Wizard, which is so magical it only has a single screen depicted below:




At the very top is the Database/Table combo box where you select what table from what Database you want to export.


Some Alventis tables may be relationally linked. We discuss Relationality elsewhere. All that's important to understand is that if Alventis notices that there are any tables that the selected table references, such tables will be listed in the grid.


The Export Relationally-Linked Tables checkbox, when checked, will export not only the main table you selected, but also all the tables it references. If you know what you are doing and understand the implications, you can uncheck this checkbox, thus only exporting the main table.


The Forms grid lists all InfoView forms that "belong" to all the tables you are exporting the main table and the relationally-linked ones, if any. You can export whatever forms you want by checking/unchecking the Export checkbox for each form.


The Export Table Data checkbox, when checked, will make the Wizard export the data of all exported tables.


Output Folder should be set to the path where you want to export the InfoSet. It is preferable that you set it to either an existing empty directory or specify a new directory. Alventis will attempt to create it in the latter case.


Output File Name is the name you want for the export file. Whatever gets exported (and it can be quite a few files) will be zipped by Alventis in a standard Zip file with whatever name you specify here. You don't need to add the .zip extension: Alventis will do it for you. If you end up specifying a file name that cannot be used (e.g., because you include some illegal characters in it), Alventis will use the default file name which is simply "InfoSetExport" followed by the date/time of the operation.


Export Comment gives you an opportunity to attach a comment to the exported InfoSet. Whatever may be useful when you or somebody else decides to import it.


As soon as you specify a proper Output Folder, the Export button becomes enabled, and clicking it will perform the requested operation. Essentially, that's all there is to it.



Multi-InfoSet Export. You can export a single InfoSet as we have seen above. You can export more than one InfoSet following the same exact procedure. If you export multiple InfoSets in the same Output Folder, this will simply create a Multi-InfoSet Export package, which will still end up as a single Zip file. You can of course export one InfoSet to one Output Folder, and another to some other directory, if that's what you prefer.


Multi-InfoSet Export must be performed and completed without closing the InfoSet Export Wizard though. The reason for this is that whatever you export during a Wizard's "session" is zipped according to the settings you have specified at the time when you close the Wizard. Once the output has been zipped, you can't add anything to it, so subsequent Export operations even into the same Output Folder will be treated as separate and will result in new, separate Zip file(s).


A word of caution. You should never combine multiple InfoSets from more than one Database in a single Export package. It might work or at least seem like it has worked fine (if all relevant table and InfoView IDs happen to be unique), but generally-speaking this is an unsupported operation that you should not attempt.


Technical note. Alventis may create and leave a hidden file called dbisam.lck in the Output Folder. You may not be able to delete this file until you exit Alventis. You can delete it manually once Alventis has released its "hold" on that file.


It is now time to see how we can import back into Alventis something previously exported.



BarIfxInfosetImport InfoSet Import is performed by clicking the Import InfoSet button. This launches the InfoSet Import Wizard. In the spirit of Alventis, this Wizard too accomplishes all of its sorcery with a single screen depicted below:





Before we go any further, you should remember that an Import operation will modify your local data. If you ever make a mistake, such modification can lead to drastic results, including data loss. You should therefore have a secure recent backup of your data before you attempt importing something into it. This said, let's proceed.


Destination Database is the Database into which you would like to import something. It may not be the first control on the form in the left-to-right order, but you may still want to pick the Database first. Nothing terrible will happen if you don't. Except that under some circumstances, the Wizard's initial inclination to import (or not) a particular table may be influenced by the currently selected Destination Database, so you might have to do more work later (check a checkbox it decided not to check for you, that is).


Import From is a Text Box where you specify the name of the Zip file that contains the InfoSet package you or somebody else has at some point in time exported from Alventis. You must specify the full filename with the path. You can use the little dotted button to browse for the file you want using the standard Open dialog.


Import Comment is a read-only box that displays the Comment that was specified by whoever prepared the InfoSet package.


As soon as you enter a proper Zip file name in the Import From box, the rest of the form comes to life according to what InfoSet(s) the specified Zip file contains and what your chosen Destination Directory is.



The Tables grid displays a list of all InfoSet tables that were found in the package. We'll go over its columns now.


ID is simply the table's ID whatever it happened to be in the Database from which someone originally exported it.


Created/Modified/Name/Caption/Comment are the usual information-only columns.


Local indicates if you have a table with the same name locally, i.e., in the selected Destination Database. InfoSet Import cannot rename tables. If you are importing a table called Contacts into a Database that already has a table called Contacts, this in itself is fine, but Alventis understands your intention as one to transfer some data from the Contacts table in the package into your local Contacts table. This is precisely what the Local checkbox indicates.


Structures Match. If Local is true, i.e., you have a local table with the same name, the structures of the table you are importing data from and your local table must match exactly, as if this were the same table. The Structures Match indicates if this is indeed the case. It is only applicable when you do have a local same-name table, so it will be grayed-out if you don't.


Match Recs indicates the number of records with matching IDs. This is of course only applicable if you have a Local same-name table.


Unmatch Recs indicates the number of "incoming" records with IDs that you don't have locally. This value is meaningful regardless of whether you have a Local same-name table. If you don't, it will simply equal the total number of "incoming" records.


Dependents will list each table's dependent or linked tables, i.e., other tables it may be referencing, if any. When importing Relational InfoSets, you must import a table together with whatever tables it references. This column will give you an indication if this is the case.


Import checkbox is finally something you have direct control over: check it to enable the import from the corresponding table. When importing from Multi-InfoSet packages, you may want to perform the import from only some tables, so this is where you'd specify which ones.


Import Mode deserves special attention, so we will explain it shortly, once we've covered the rest of the form.


Message will display hopefully helpful hints or explanations the Wizard may have regarding each table. For example, if a particular table cannot be imported (e.g., due to a structure mismatch) this is where it will tell you.



The Forms grid lists all associated InfoView forms and is luckily quite simple.

Table tells you which table the InfoView "belongs" to.
SpecID is the original ID number of the InfoView at the time it was exported.
Name/Caption/Comment are what they seem.
Import checkbox allows you to tell the Wizard to import some but not other forms.



Import Modes. Depending on various factors, certain import operations may or may not make sense or even be possible. These factors include: Local, Structures Match, Match Recs, Unmatch Recs. Together, they tell Alventis what can and cannot be done with a particular table or its data. The specific logic used is quite complex but it simply follows the "common sense" logic of the situation, so you can usually figure out fairly easily why only certain choices are presented for certain tables if you feel like it of course.


The possible values or choices you may see are:

Can't Import. This simply indicates that importing is impossible for some reason.
Nothing to do. This means the Wizard arrived to the conclusion that the table in question doesn't need any import (likely because there are no records to import and the structures already match).
Structure Only. This choice allows you to import the table's structure but not the data.
Append All / Preserve IDs. All records will be appended with their ID values preserved.
Append All with New IDs. All records will be appended but their ID values will be auto-set to whatever the next "empty slots" in the local table happen to be.
Skip Matching, Append New Ones Preserving IDs. Almost entirely self-descriptive, this means that any matching records with same ID values will be ignored completely, and any new records for which there is no local matching ID will be appended with their "incoming" IDs preserved.
Skip Matching, Append New Ones Resetting IDs. As above, but the "incoming" IDs will get auto-set.
Update Matching Only. Records with matching IDs will be updated (local ones will be overwritten with whatever is in the "incoming" ones), nothing else will be done with unmatching records, if any.
Update Matching, Append New Ones Preserving IDs. As above, but records with IDs that don't exist locally will be appended preserving their ID values.
Delete Matching Only. This seldom-used option will delete whatever local records have a matching "counterpart" with the same ID in the import package. Nothing gets imported.


If you just read the above list of Modes for the first time and don't have much experience importing InfoSets, it may look quite daunting. In most cases though, you won't have to face too many complicated choices, and never all of them at the same time for the same table. Alventis always tries to suggest the most common Mode. In some cases more than one may indeed be available, and it is only you who can decide what makes most sense based on your knowledge of what you are importing where. We may not be able to make that choice for you, nor even provide you with an exhaustive list of possible scenarios and suitable Modes, so you may occasionally have to resort to common sense and decide what you want to happen to matching and unmatching records.


The most basic reasoning is therefore this. Some incoming records may be "matching", i.e., their IDs match those of the locally-available ones. Others may be "unmatching" with no local counterparts. The number of such records will be displayed in the Match Recs and Unmatch Recs columns respectively.


Matching records can be skipped, imported "over" the local ones (update), imported with their IDs changed (in case, for example, the IDs match by accident and don't indicate any true relation between local and incoming records), and lastly you can just have the local ones deleted. There's no other conceivable operation you can perform on the matching ones.


Unmatching records may be skipped, imported with their IDs preserved (since they don't have any local matches, so the local ID values are "available"), or imported with their IDs changed.


Most sensible combinations of the above are available, so you can usually pick the right Mode based on how you want to handle the matching and unmatching records.


You should also remember that ID values may have a special meaning for some records. This is especially true of relational tables. The table in which some other table performs "lookup" using the record ID values must obviously preserve its IDs, otherwise relationships between data records risk getting broken.