PDF Print E-mail

Frequently Asked Questions

 

The following questions are presented in no particular order.  Use your browser's search facility or the search at the top right of this page to find any particular topic.]]>


I cannot justify allocating days of my time to evaluate this system.  How long will it take for me to get the system up and running?


The initial installation will take a minute or two at most, and this will provide everything that you need to start up a Primary Server and log on with the Administrator, Query and Blueprint.  The only delay will be obtaining an evaluation license key for your trial installation, which may take 10 or 15 minutes depending on e-mail latency.

 

The quick-start guide will run you through the simple set of steps to get the sample database installed and working.  Everything needed for initial evaluation, including worked examples, is included in the install.

 

You should be logged on to Blueprint and looking at the first example within 15 to 20 minutes of commencing the install, or connected with Query and executing sample SQL statements in the same amount of time.

 


If I install the Blueprint development system, will I have some examples to get me going?


Multiple examples are provided, ranging from project structures and dictionary design through to LavaStream source code.  In addition, multiple working template examples - coded in LavaStream - are provided.  All of this is part of the Blueprint development database provided with the installation.  This means that worked examples of all facets of programming are accessible from Blueprint, providing in addition examples of how projects are structured.



What operating system can I use for the server / client?  What is the recommended operating system?


It is possible to run either server or client on any of the following :

 

Windows XP

Windows Vista

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2

Windows 7

 

For all of the above, either 32-bit or 64-bit variant may be used.

 

We recommend Server 2008 or R2 for the Lava Server, and Windows 7 for the client.  There are significant network and memory management improvements in these releases which improve performance and reliability.  Windows Vista works fine as a client, but Windows 7 does seem to be quicker and more stable.  If you use Windows XP as a client, ensure that you have service pack III installed. XP is not the best option for a client, though, since neither the network layer nor the memory manager are at the same standard as Windows 7 or even Vista.

 

Older operating systems (Windows 2000 and before) are not supported at all.  No Linux or Apple release is planned at this time.



I have an existing database.  How easily can I import the data into a Lava database?


Facilities are provided within the Blueprint environment to import data table structures directly from foreign databases.  Import code can be generated directly from these table definitions using template code provided as part of the system.  With virtually no additional programming, these procedures can be executed to effect data import.



I have a complex database design currently implemented in MySQL / Oracle / SQL Server (or other).  How can I port this design into Lava?


The Blueprint design environment provides a fully automated mechanism for importing schema designs into a Blueprint dictionary.  The source database must support ODBC, and specifically the table format interface in ODBC.  This is true for all the major databases (but for example not provided in Pervasive SQL).

 

In order to import the database design, a login dialog from the vendor is displayed which allows entry of a valid user and password, following which a list of available schemas is presented.  You can either import an entire schema (which will import every table in the schema) or elect to import a table at a time.  Either way, each table imported will be defined in the Blueprint dictionary exactly as defined in the source database.

 

Once you have completed the import, you may use this dictionary as you would any dictionary in Blueprint - including generating data import source code, which the system will do automatically.



My existing database is very large.  How long will it take to import the data?


Data import into a Lava database is very fast.  Provided a fast server and especially a fast workstation is being used, sustained data rates of 20,000 rows per second or higher can be maintained over extended periods.  This will, of course, also depend on a well-configured network.  If higher data rates are required (extremely large imports) the import procedure can be run after mounting the database exclusively - this will allow data insertion rates of up to 60,000 rows per second.  In the majority of cases, the greater part of the time taken to import data is the time used in extracting the data from the source database.



I want to make some design changes to my data while importing.  How easy will this be?


Imports are executed using LavaStream code.  Since LavaStream is a powerful general purpose programming language, including any and all language facilities you could possibly need.  Any data translation, ranging from simple to extremely complex, may be undertaken during or after the import process.



I have many reports written in Crystal which I use on my existing database.  Will I be able to use these on a Lava database?


Yes.  It is possible that minor changes may be required to SQL statements if uncommon or unsupported clauses are used, but this will normally not be the case.  Generally, the report should run without (or with very little) alteration.



I have a large amount of code in PHP running on my existing database.  Will I be able to use this code on a Lava database?


Generally, this should be possible.  However, you will possibly have to change the database driver used.  If, for example, you are using the MySQL driver to interface to the database, this will have to be changed to the generic ODBC driver - in some cases this may require a number of code changes since PHP does not use a uniform syntax for its SQL statements, and editing will be required.



My existing applications are written for MySQL / Oracle / Sybase / SQL Server.  Will I be able to use these applications on a Lava database?


This will depend on exactly how these applications are written.  In some cases, it may be as simple as changing the database driver or the database specification.  In other cases, minor edits or rewrites may be required to render the application compatible.  In some cases, manual translation of trigger procedures may be necessary.  In the most extreme cases, rendering the application compatible may be as much work as a complete rewrite, rendering it impractical.  This last is unlikely, and will only be the case with very few applications typically written for a more uncommon database or where very specific non-generic target database facilities are used


One thing to be kept in mind is that a translated application will remain a client-server application.  This will at best work not much better (perhaps 20% or so) than it did on the original database.  Native Lava Distributed applications provide significant advantages to the user in terms of reponsiveness and even in terms of interfaces and devices available to the programmer.



I need to process vast amounts of data on a regular basis.  How will a Lava database improve my current server load?


If the data processing is performed on the server, the sole advantage will be the improved speed of the Lava Server as compared with other databases.  This can be quite large in specific instances, but in general is no more than 20% or so.

 

If, however, the processing is written using the distributed facilities of the Lava Distributed SQL system, there are significant advantages. Since the primary processing is done on the client, the majority of the processing load is moved away from the server.  The server only applies data modification after all validation and relational processing has been completed.  In this case, the server load is significantly lower than would normally be the case.  Server processing may fall by as much as 80% in some cases.



I will be writing part / all of my applications in C / C++ - how well is this option supported by the Lava development system?


Development in C is fully supported.  Header files are supplied for the complete Lava API, as well as for the Lava Runtime and the Gadgets package.  Template code is provided to export dictionaries in the Blueprint environment to header and C code allowing direct interface to any tables designed within the system.


In addition, several coded examples in C ranging from simple to complex are provided to assist in mastering the Lava system.



I am intending to develop a very large project.  How well will the Blueprint development environment cope with this scale of project?


The Blueprint environment was specifically designed and intended to support projects of all sizes. Although small projects are simply supported, the real strength of Blueprint is with huge projects. As an example, the entire Blueprint project itself is created and maintained in Blueprint. The greater project involves 41 executable images (DLL and executable) and over 700,000 lines of source code in over 1,500 source modules for the product release alone.  In addition, the development database includes about as much code again in the form of prototypes and legacy code. However, the capability of Blueprint goes far beyond this, and projects multiples of this size should present no problem - the project described above presents no strain to the Blueprint system whatsoever.  For example, a comprehensive re-make of the entire project takes under 2 minutes.

 

 

My project will have a very large schema, with hundreds of data tables and perhaps a thousand relations.  How well will the Lava database cope with this many tables?


The basic Blueprint installation sets up a design database which already contains over 1,000 data tables. The database is designed to operate without performance constraints up to 20,000 data tables or more. As for relations, database performance would not be adversely affected with 100,000 relations.

 

 

I expect to support over a thousand clients from my database server.  How will the Lava server behave under this kind of load?  What kind of hardware will I need to plan for?


This will depend in part on the type of client you wish to use. Conventional client-server (non-distributed) clients are a very small load on the system, and 1000 clients of this type will present no problem to the server.

In the case of distributed clients, however, there is additional load on the server due to the requirement to re-distribute updates to all connected clients. Practically, no more than 200 or 300 distributed clients can be connected to any one Lava server (depending, of course, on the server configuration.  Powerful servers may handle 5 or more times this load). This means that in order to support 1,000 distributed clients it may be necessary to configure a server network including 3 or more Satellite servers. This will support the number of clients you require.

The implication is that your hardware cost will include the cost of approximately 4 servers at a cost of approximately $1,500 each, as well as licence cost for the Satellite Servers.

 

 

I want to be able to run the database server and the primary application in Australia, but provide management information to our head office in Europe.  How will I do this using a Lava distributed database?


There are two ways to achieve this, depending on available bandwidth and number of users at head office.  If only one or two users at head office wish to access the information, and the bandwidth to the Australian site is reasonably good (1Mbit/s or so), you could simply connect to the database directly from head office and everything should work reasonably acceptably.

 

If the number of users at head office is higher than this (5 or more users, for example) or the bandwidth is not very good (500 Kbit/s or worse) the better way would be to configure a Satellite server at head office to provide a remote server for these users.  This Satellite Server will connect to the Primary Server in Australia, and will provide a local source for the majority of the information required.  Users at head office log on to the Satellite server, and will in general see application response times closer to that of a LAN than the latency and bandwidth delays imposed by the remote link.



What are my options for developing client applications?


It is possible to develop client applications exactly as for any other client / server database, using SQL as the primary interface.  This may be done either through the ODBC driver, or through the proprietary Lava API, depending on requirements and interfacing constraints (The Lava API is a set of interface procedures which use the same calling convention as the Windows API - comprehensive interface definitions and examples are provided for C or C++).

 

Alternatively, the client application may be designed and implemented as a distributed SQL client.  This mandates the use of the Lava API, and allows a very wide range of additional database interfaces including row-level operations, seek mechanisms, a variety of information functions, and much more (over 200 individual function calls).

 

Using the distributed SQL approach, application design will be much simpler, as the application is designed and written as if it is a single user application on an exclusive mount database.  For new applications this is the recommended route.


 

I have an existing Web database (currently MySQL / Oracle / SQL Server) which I do not wish to change.  If I develop an application on the Lava database, how can I interface to my Web database to provide this data to my existing Web applications?


The Lava API as well as the LavaStream language provide ample interfaces to ODBC functionality which allow for accessing foreign databases   These interfaces may be used to connect to, extract from and insert data into a foreign database, the only requirement being that the database in question must have a good quality ODBC driver which supports the core of the ODBC 3 specification.  This is certainly true for all of the major databases (MySQL, Oracle, SQL Server, Sybase, Informix, Systems Cache and several more).  There are some databases (for example Pervasive SQL) which do not support certain functions and where functionality may be slightly limited, but in general (and certainly for the major databases) there should be no problem.  Even for databases like Pervasive SQL there are typically adequate workarounds for the shortcomings in the driver.



Does Blueprint have an application developer that will allow me to build a GUI application using a screen designer and rapid application development techniques?


At the current time the application developer integrated in Blueprint is not yet ready for release.  Although the majority of the work on this subsystem has been completed and large parts of the system have already been tested, we only anticipate releasing this system at the end of the first quarter 2010.



What debugging facilities are available in LavaStream?


A fully-functional symbolic debugger is provided for LavaStream,  tightly integrated with the Blueprint editor.  All standard debugging facilities (step, breakpoints) are supported including facilities for debugging output to a text area.

 

 

Can I do C or C++ development from within Blueprint?


We are working towards this and intend to provide full support within a short while.  At the moment it is still necessary to develop under an environment such as dotnet.