Install

From Team Developer SqlWindows Wiki
Jump to: navigation, search

Install & Deployment


Contents


Pointer2.png TD startup batchfiles Pointer.png


BEWARE: read this info first before starting any of the supplied batch files.
You must inspect and change the batchfile contents to fit your system and needs.
The usage is at your own risk !!!!


When multiple TD versions are installed, the system PATH settings can interfere with each other.
Also when applications build with different TD versions the PATH setting can be an issue.


Developing applications means you have a set of sources (app/apt/apl) and probably use a set of resources.
(like bitmaps, icons etc).
Depending on the project you also define external functions from custom dll's which are stored at a specific location on your system. Lastly, you might use dynalibs which are .apd files somewhere on your system.


To be able to compile, all those files must be accessible by TD at compile time.
This means that TD must be able to find them on your system. By setting your system PATH setting you can add folder locations
which then will be used system wide (for all applications on your system).
But that is not enough: even when the system PATH contains your folders, TD will not use this setting for all files in your project.


This is how TD searches for files when compiling:


  • When all files are in one folder, TD will find them all
  • When a source file (apl) is not in the same folder, it will use the configured folder location in the TD preferences.

(the system PATH is not used to find the sources by TD)

  • When a resource is not in the same folder, TD will use the system PATH to find it
  • When a dll is not in the same folder, TD will use the system PATH to find it
  • When a dynalib is not in the same folder, TD will use the system PATH to find it


When you have a simple development system with only one project to develop on, the needed changes to the TD preferences and system PATH can be easily configured.
But what on development systems which have several TD versions installed and several projects per TD version to be developed on?


It is much harder to setup such systems, specially when you are working on those projects simultaneously.
For each TD version and each project you will have to change the settings. And errors are easily made. A wrong folder in your system PATH
could mean that TD is using wrong dll versions or resources which are meant to be used on another project.


A solution to help out is to use batch files to start TD which configure the settings automatically.
Having multiple batchfiles, each configured for a specific TD version and/or project will enable you to quickly switch between TD versions and projects.
Also, the system PATH settings done from a batchfile are not system wide. Other applications running on your system will not use
the settings made to the system PATH variable. Only for the application you start from the batchfile.


To give you a working starting point for such batchfiles, an archive is available containing batchfiles for all TD versions.
By changing these batchfiles to your needs you can setup a development environment with minimal effort.


This archive is meant to be as a template to create your specific batch files.


WHAT ARE THE FEATURES OF THE BATCHFILE


  • Starting the batchfile (eg double-click on the batchfile):

The needed PATH settings are configured.
a) The TD IDE installation folder is added to PATH system variable
b) The application runtime folder is added to PATH system variable
c) The sources folder is added to PATH system variable
d) The resources (eg bitmaps, icons etc) folder is added to PATH system variable


The needed PATH setting in the TD preferences will be configured.
a) The TD IDE installation folder is added to global search path in preferences (registry)
b) The sources folder is added to global search path in preferences (registry)
c) The resources folder is added to global search path in preferences (registry)


TD IDE is then started


  • Dragging a source file on the batchfile (icon on desktop or in Windows Explorer):


The needed PATH settings are configured.
a) The TD IDE installation folder is added to PATH system variable
b) The application runtime folder is added to PATH system variable
c) The sources folder is added to PATH system variable
d) The resources (eg bitmaps, icons etc) folder is added to PATH system variable


The needed PATH setting in the TD preferences will be configured.
a) The TD IDE installation folder is added to global search path in preferences (registry)
b) The sources folder is added to global search path in preferences (registry)
c) The resources folder is added to global search path in preferences (registry)


TD IDE is then started and will automatically open the dragged file


  • Dragging an executable (exe, build with TD) on the batchfile (icon on desktop or in Windows Explorer):


The needed PATH settings are configured.
a) The TD runtime installation folder is added to PATH system variable
b) The application runtime folder is added to PATH system variable


The dragged executable is started using the configured TD runtime.


HOW TO SETUP THE BATCHFILE


  • Determine for which TD version(s) you want to use a batchfile (eg TD 4.2, TD 6.2 etc)
  • Open the batchfile you want to use in a text editor (DO NOT START THE BATCHILE)
  • Edit the batchfile. Check all batch variables and change the values according to your specific situation


These variables have to be checked and changed when needed:


PROGFOLDER
This variable points to the program files folder where you have installed TD.
It only specifies the base folder which is the base for all installed software on your system.


Normally this is 'C:\Program Files' (on 32 bit) or 'c:\Program Files (x86)' (on 64bit)


When you use the C: drive and the default Windows location, you do not need to change this variable.
The batchfile will check automatically if you have a 64bit program files location. If so, the variable
will be set to the 'c:\Program Files (x86)' folder. If this folder is not present on your system, it will use
the 32bit location, which is 'C:\Program Files'.


TDVERSION
This variable is only used to display the TD version in the DOS window.
Change this to the TD version you use or define any other display text you want to have displayed


TDEXE
This defines the executable name of the TD IDE. For instance cbi61.exe (for TD 6.1) or cbi31.exe (for TD 3.1).
The batch file will execute the configured TD executable name.


TDINSTALL
The folder location where TD is installed on your system.
You can set a full PATH to this folder or use the PROGFOLDER variable as base.
For example:

  • TDINSTALL=d:\Software\Gupta\Team Developer 6.2
  • TDINSTALL=%PROGFOLDER%\Gupta\Team Developer 6.2


TDRUNTIME
The TD runtime installation folder. This could be the same as the TD IDE installation folder when you do not
have a TD runtime installation on your system.
For example:

  • TDRUNTIME=D:\MyApplication\RuntimeTD62
  • TDRUNTIME=%TDINSTALL%


TDREGISTRYLOC
The registry location where TD stores the global search path settings (TD preferences->directories)
BEWARE: the batch file will write a value to that location. Any value present will be overwritten.
Also be sure the location is correct. First inspect the registry to see the variable is pointing to the correct location.
For example:

  • HKCU\Software\Gupta\SQLWindows 6.2\Settings
  • HKCU\Software\Unify\SQLWindows 6.1\Settings


APPRUNTIME
The folder location where runtime files of your application.
This is mostly the application installation path where custom dll's, exe's, ini's and dynalibs are located.
You can specify multiple locations by using ; as separator
For example:

  • APPRUNTIME=C:\Program files\MyApplication
  • APPRUNTIME=D:\Development\MyApplication;D:\Development\MyDlls


SRCFOLDER1
Folder location(s) where your sources are stored (app/apt/apl).
You can specify multiple locations by using ; as separator
For example:

  • APPRUNTIME=D:\Development\Sources
  • APPRUNTIME=D:\Development\MyApp;D:\Development\MyApl


RESFOLDER1
Folder location(s) where your resources are stored (bmp/ico etc).
You can specify multiple locations by using ; as separator
For example:

  • APPRUNTIME=D:\Development\Resources
  • APPRUNTIME=D:\Development\MyBitmaps;D:\Development\MyIcons


TDREGISTRYVAL
The value to put in the registry for the TD global search path.
The registry location is defined in the TDREGISTRYLOC variable.
Mostly, the value should be the location of your sources and resources and also
the location of your TD installation folder.
You can use the configured variables or use full paths.
You can specify multiple locations by using ; as separator

  • TDREGISTRYVAL=D:\Development\Sources;D:\Development\Resources
  • TDREGISTRYVAL=%SRCFOLDER1%;%TDINSTALL%;%RESFOLDER1%


In most cases, changing the mentioned variables is enough to have a valid working start-up batchfile.


HOW TO USE THE BATCHFILE

  • Start batchfile to open TD IDE (empty project)
  • Drag source file on the batchfile. It opens TD IDE and will load the source
  • Drag executable on batchfile. It starts the executable with the needed TD runtime


USE BATCHFILE FROM WINDOWS EXPLORER CONTEXT MENU
1) Right click on app/apt/apl file
2) Choose "Open with"
3) Browse to the batchfile and select it
4) Uncheck the “Always open with" checkbox when you want to keep the default action OR
Check the "Always open with" checkbox when you want to use the batchfile for default.


(You can always change the behaviour later by doing step 1-4 again and change the options)


Here you can download the TD startup files archive:
Down.png TD_Startup_BatchFiles.zip


Pointer2.png Coexisting runtime versions Pointer.png

When deploying applications developed using Team Developer, you also have to deploy the correct TD runtime version to your clients PC. If you have more than one project developed using any Team Developer Version, you may face the need to deploy more than one TD runtime version at a time because keeping every project in the same TD version can be impossible. There are several ways to solve this problem.

  1. Deploy into the same directory
    This is the way my company used to deploy the TD runtime versions until TD 5.1 came. As lots of the TD files have the version in their filenames, copying them together into the same directory worked.
    We had the versions of TD 1.1, TD 1.5 and TD 3.1 installed in parallel. For the files, that have equal names, we tried if the newer versions worked for TD 1.1 and TD 1.5 applications too. We were glad, that it worked.
    Important! Mixing TD 5.1 files with older versions doesn't work! Only files of ANSI-TD-versions may be mixed in one directory!
  2. Deploy into the application directory
    This might be a solution for you, but personally, I don't like it very much. As the TD runtime is just a bunch of DLL files, you may copy them completely into your applications installation directory. So every applications has it's own TD runtime.
    Important! Verify that your application's installation directory is not enlisted in the system-PATH. You may get some DLL's loaded from different places which may cause problems!
  3. Deploy using different directories and start batches
    As you can read at the end of the first described way, mixing TD 5.1 files with older TD files does not work. Especially the native database routers, which all have the same name in every version, make problems. To solve this, I decided to create multiple directories for the files by still having only one SQL.INI file on the system. As TD applications need cdlli??.dll on startup, you have to ensure that they can be found. This may be done using start batches like this one.
    REM Filename: run_td42_app.cmd
    set PATH=<TD 4.2 Runtime Directory>;%PATH%;
    start td42_app.exe
    

    This will extend you system-PATH temporarily with the TD runtime files directory and start the application. You'll see a console window flickering by which happens when the batch starts. If this doesn't bother you, it will be an easy way for solving this.
    Pros: simple, also works from command prompt
    Cons: flickering console window, file has to be run with full path if not in system-PATH

  4. Deploy using different directories and "App Paths"
    If the flickering console window bothers you, this way could be the one of your choice. Windows Explorer has the functionality of "App Paths" which allow you to define a different search path for every single EXE file in the system. It may look like this for the example above.
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\td42_app.exe]
    @="C:\\Program Files\\<application installation directory>\\td42_app.exe"
    "Path"="<TD 4.2 Runtime Directory>"
    

    Pros: no flickering console window, just running "td42_app" from "Start->Run" finds the application, even if it's not in the system-PATH
    Cons: doesn't work if you run the EXE from the command prompt


For all solutions keep SQL.INI in mind. TD will search for SQL.INI in the system-PATH, so keep track of all SQL.INI files on your system. Having multiple SQL.INI files may cause problems if your application finds any SQL.INI in another directory than the one where your SQL.INI-to-use is in. In my setup, I decided to place the SQL.INI in my "TD runtimes base" directory, and using "App Paths" for the applications.
The directory structure looks like this:

C:\Program Files\TD Runtime             <- contains SQL.INI, added to system-PATH
C:\Program Files\TD Runtime\3.1         <- contains TD 3.1 runtime files, not in system-PATH, no SQL.INI
C:\Program Files\TD Runtime\5.1         <- contains TD 5.1 runtime files, not in system-PATH, no SQL.INI


Pointer2.png ProfUIS283u_td.dll vs. ProfUIS283u-RDE.dll Pointer.png

Since Team Developer 5.2, those two DLLs are included in the runtime files.
First, I thought, that the second file, ProfUIS283u-RDE.dll, is not needed as everything worked without it.
The IDE and the compiled applications.

But then, I recently found out, that Report Builder needs it.


So, if you don't have Report Builder reports in your application, you don't need ProfUIS283u-RDE.dll to be deployed.
But as soon as you have RB-reports, you'll have to include it.


By the way, I have absolutely no idea, why they built two quite similar DLLs!