Results 1 to 5 of 5

Thread: Move Virtual Tables From Windows to Centos

  1. #1
    Senior Member
    Join Date
    Jul 2013
    Location
    Ontario, Canada
    Posts
    658

    Move Virtual Tables From Windows to Centos

    Hello,

    I wish to try moving my virtual tables from my local windows directory to the centos server where the actual dbf files are stored to see if performance can be improved.
    What would I need to do to make this happen?

    I know it's not as simple as 'cut and paste' since Lianja needs to know where the virtual table is stored so it can access its properties.
    I have many virtual tables and it would be best if I could move a few over then test to see if performance has improved and repeat as required.
    I have a mapped drive to the centos server and I have also tried changing the app data directory settings to the mapped drive and that didn't work.

    Cory

  2. #2
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,371
    Blog Entries
    22
    Cory,

    You need to better understand how data is accessed between a windows client and a linux server before embarking on this.

    A Virtual Table uses an ODBC connection to connect across to a linux server from a windows client application.

    When you talk about "moving virtual tables" the fact is there is nothing to move as the Virtual Table is by its definition merely a way of connecting and handling database operations from the windows client to the linux server. To accomplish this you need to have Lianja SQL Server installed on the linux server so that it can act as a database server for your windows clients.

    If you do not have Lianja SQL Server installed on the linux server then how are you setting up Virtual Tables? Are these just "local" accessing a network shared drive? Sounds messy and slow as all the data will be pulled across the LAN to the local windows client. Thats not client/server. Nothing you do will speed up a 1Gbps LAN. If you have apps that run on windows that share data on linux with other linux apps then you need to design for that scenario.

    "I have a mapped drive"?... I'm confused by this. What does a mapped drive have to do with Virtual tables? You either share the data on a network drive or use VTs -- not both as that does not make a lot of sense.

    If you are just using a shared drive on windows and you have correctly setup and configured samba on linux then you can access the linux data AT RUNTIME in shared mode while you linux applications are accessing this data.

    You cannot be accessing your live linux data exclusively from your development IDE while your users are running shared applications on the linux server

    You need to create local copies or have a "staging database" to work with as I have described on these forums several times.

    In v1.3.1 there is a new command line switch called --runtimedatadir which can be specified on the desktop shortcut on windows. e.g.

    --runtimedatadir x:\

    So if you have mapped a network drive to x: on your desktop clients they can access the data on linux using this.

    You should not be accessing the live linux data from the development IDE which uses exclusive data access.

    As I have mentioned on several occasions, setup a development database, a staging database (for testing live apps) and a runtime database. This is best practices.
    Last edited by barrymavin; 2015-02-20 at 23:35.
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  3. #3
    Senior Member
    Join Date
    Jul 2013
    Location
    Ontario, Canada
    Posts
    658
    Hi Barry,

    This thread stems from several open tickets where I have addressed concerns regarding the speed of using virtual tables.
    I am trying to improve the speed any way I can.

    I didn't think it was possible to move virtual tables although I had to look into this as a possibility.
    SQL Server is installed on the Linux machine and the DNS entries are listed on both systems.
    The virtual tables do use an ODBC connection. None of them are 'local'.

    Originally I used ADD TABLE with the mapped drive although I changed everything to virtual tables.
    Based on your comment:
    If you just create your database on the server and use ODBC the SQL query is performed in the actual server and only the result set is fetched back over the LAN.
    I thought I might be able to place the virtual tables in the mapped directory to see if it would process the information any faster.

    The data on the Linux machine is live test data. Nobody else accesses it except me for use with Lianja.
    The data is not being accessed from any other application either. There are also no shared users in this case.
    The files are duplicates of the actual tables so that I have real data to access and test with and to duplicate real world functionality.
    I believe the data is converted Recital tables and the goal, as per my understanding, is to eventually use both Lianja and Recital to access the same data.

    Improving performance is now a critical issue for me.
    Since I haven't received any further assistance from the Lianja team for several months, I wanted to reach out to the Lianja community for assistance.

    Overall, here is my (main) issue:
    - My app has under 3 dozen virtual tables (several of which were only added to test additional features)
    - I believe most, if not all, virtual tables use an sql statement that includes where 1=0 and is altered as required.
    - All virtual tables use an ODBC connection to the Linux server.
    - In Lianja, if I only open the database from the data workspace, it takes just under 2 minutes before I can see the tables.
    - Using the Lianja app, the data retrieval and update may take upwards to several minutes to complete.
    - Loading the app takes several minutes (most of that time seems to be used for loading the data, yet once the 'ready' event is reached from the main page, it only takes about 6 seconds to complete after performing several functions
    - The Linux server is only about 10 feet away from the development computer.

    As a guess, I'm assuming Lianja is creating a new connection and testing it each time a virtual table is accessed.
    This is my guess on why it slows down so much.

    I don't think most of the issues should be discussed here although I thought that there perhaps some developers may have some knowledge that could help me out.

    Thanks,
    Cory

  4. #4
    Lianja Development Team barrymavin's Avatar
    Join Date
    Feb 2012
    Location
    UK, USA, Thailand
    Posts
    7,371
    Blog Entries
    22
    No Lianja is not using a connection for each virtual table, it uses connection pooling.

    The distance between the computers makes no difference. They are connected on a LAN which I assume is 1Gbps.

    You are asking us to help debug your application to determine what is causing the slow loading of it.

    The only way this can be done is to have your windows application and a zipped up version of your CentOS data. Without that we cannot help you. Providing this level if support is very time consuming and really needs to be discussed by email.

    The forums are not for support at this level and this is above our standard support level.

    This issue is specific to your use of linux as a server but there is no proper explanation of what the linux server is doing, what it is running in parallel to this etc.

    This should be discussed on a ticket not on the forums.
    Principal developer of Lianja, Recital and other products

    Follow me on:

    Twitter: http://twitter.com/lianjaInc
    Facebook: http://www.facebook.com/LianjaInc
    LinkedIn: http://www.linkedin.com/in/barrymavin

  5. #5
    Senior Member
    Join Date
    Jul 2013
    Location
    Ontario, Canada
    Posts
    658
    Hi Barry,

    Thank you for your response.
    I have sent an email to the support email address.

    Cory

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Journey into the Cloud
Join us