The Definitive on Virtual Tables

I thought this forum might be the best place for this thread.
Spending a few hours reading as many posts on Virtual Tables as possible there has been no definitive answer on “should they be used exclusively or not?”

From my readings VT’s offer portability and encapsulation and some posters feel the “anywhere and any database” is best.
HOWEVER:
If the Lianja SQL Server is as good as written up here why would you build in any other SQL? If you were to develop exclusively in the Lianja SQL what is the best practice? Would you just go native or cursor adapter?
Granted if connections were required to a foreign SQL based system then VT’s would be used.

Some references:
http://www.lianja.com/community/show...virtual+tables
http://www.lianja.com/community/show...virtual+tables

Hi Paul,

Using VT's give you great flexibility in terms of putting LSQL on another server, or at a customer's request/need, hitting the backend of their choice.

I agree LSQL is a great way to go. I've created a generator for Delete RI that uses a stored procedure (created through metadata imported from xCase). This should be the fasted Delete RI available, since nothing is faster than a SEEK, except a SEEK that doesn't move the file pointer.

Hank

Thanks Hank - yes I did read some of your correspondence on VT's.

Whats is the next best alternative to VT's if I elect to only use these for "other SQL's"? Also not using VT's does this meet the "no Code" (or less code) in the case of not using VT's?

Paul.

Hi Paul,

I am replacing a system that I built prior to Lianja that has hundreds of stored procedures already in MS SQL.
There's no reason to rewrite that code.

Additionaly, I am building systems that interact with other vendor products that are already on our SQL Server.

Vt allow you to really take advantage of all the built in processes like relating sections, auto insert /update/ delete etc.

I think the situation really dictates the use.

Herb

Thanks Herb - I know you and Hank have discussed VT's on many occasions.

So if Lianja SQL is the end solution what type of access would you guys suggest? I am little worried if I stay "old school" the future may leave us behind. I have lots of code that will need porting to stored procedures and being able to rebuild/move in VFP would be a massive win... Hence VT's will may offer little advantage. Also when you said "Vt allow you to really take advantage of all the built in processes"- I thought these would be available native Lianja as well?

Paul.

Virtual Tables are mainly used for accessing third party SQL databases such as MSSQL and MySQL.

However, If you want to run the Lianja Cloud Server on one machine and the Lianja SQL Server on another (think load balanced cloud connections) then VTs are one of the solutions. You can also configure the Cloud Server to access shared data on another machine.

So there are a variety of solutions for scaling out Apps which have a lot of concurrent users.

If you are building Web Apps that use the native Lianja database, this is embedded in the Cloud Server. This makes it very fast as there is no communication to the external SQL server. The functionality is better and the performance is very good.

With the ability to also use VTs in .rsp dynamic pages in v1.3 the sky is the limit for integrating external data sources.

Quote:

---

If you are building Web Apps that use the native Lianja database, this is embedded in the Cloud Server. This makes it very fast as there is no communication to the external SQL server. The functionality is better and the performance is very good.

---

Wouldn't a connstr of 'local' accomplish native connectivity speeds also? The other reason for using VT's is to show data that is more than one jump away from the base table.

thanks,

Hank

Quote:

---

Originally Posted by pauln

If the Lianja SQL Server is as good as written up here why would you build in any other SQL?

---

I'm sure it is however there are sometimes other considerations in the choice of database.

Your potential customers have heard of SQL Server, they've heard of Oracle, and so on. So there can be familiarity and nice warm feeling with those backends, rightly or wrongly.

You can find plenty of SQL Server and MySQL admins out there. Not so much for a proprietary database.

Backup software like Backup Exec has built-in support for things like SQL Server and Oracle.

Lianja Virtual tables provide database independence so that Lianja adheres to corporate standards.

Cost, performance, and real-time replication between master/slave linux servers with automatic failover and fallback is also worthy of mention when comparing the Lianja database engine.