Maximum columns in a table

What is column count in Lianja table ?

is it 256 columns? or extended ?

Thanks,
Dilip

It is 256, per System Capacities in the Lianja Wiki: http://www.lianja.com/doc/index.php/System_Capacities

BTW: a Google search on "lianja max number of columns" brings up that page. I've found that using Google to search for Lianja questions often brings me to the right Wiki page.

Hank

If that is the case, then providing large table size will not be much useful. Because of the 256 column ristriction. Vfp not able to take the full advantage of using third party RDBMS.

The vfp cursor also having that ristriction.
Because of this reason. Most of the vfp ERP apps are moving to .net.

If lianja is also same then This will be a big show stopper to develop apps with lianja backend. Why can't break this ristriction in lianja.


I gave demo about lianja in my company. They asked me this question. They said, if lianja removes that restriction. They can buy the licence and try.

Barry,
Is it possible to do?

Thanks,
Dilip

Hi Dilip,

VFP cursors' big limitation (other than crapping out randomly on SMB2 and SMB3) was the 2GB file limit, not the 256 column limit.

I find it hard to imagine a 4th Normal Form database having a 256 column table. (For a quick review of normalization: http://www.bkent.net/Doc/simple5.htm)

Hank

Hi Hank,

So, it is not possible in Lianja to extent the column limit right?

Thanks,
Dilip

Hi Dilip,

that is correct. Nor should it be. Performance goes down with additional columns unless you take extreme steps to prevent that from happening.

The literature on # of columns is clear: if you have a large number of columns in you table(s), you almost certainly have an under-designed database. I'm sure there are exceptions. But to be classified an exception, I would require an analysis of what Normal Form the database exhibits.

I've had a few occasions over the past 20 years to examine requests for more columns and in each case the solution was to make domain and table match up. If you have a real world example of a table that you think would require more than 256 columns, and think that the table is consistent with Fourth Normal Form, go ahead and post it here, 1 field per line, with field name and short description. It could be a good learning experience for us all.

Hank

Hi Hank,

I agree with you. IF it is a new application that can design as you said. But the problem is with migration.
The applications which are using more than 256 columns, those will have problem.

Not only with VFP migration, But also with .NET apps who what to migrate to Lianja after including C# and VB.net scripting languages in lianja 5.0

extending more than 256 columns is required. Ms SqlServer is supporting 1024 columns per table. Oracle table is supporting 1000 columns. It depends on the application to use more than 256 columns or not. we should give free hand to use. If anybody is more concern about the performance, they will not use more columns.

Thanks,
Dilip

Hi Dilip,

My new apps are running in parallel with my older apps. The data is mostly on SQL Server as I have many hundreds of stored procedures.
I still use those stored procedures on SQL Server and return the data to Lianja. The same way I would in C# or C++.

I call the stored procedure using SQLConnect and return the data into a temporary table.

If you have an app that that needs a 500 columns, just keep the data in SQL Server. I cant imagine that you need to view that many columns at once.
Just grab what you need.

Or if you really want the data in Lianja, logically partition multiple tables. It's not a difficult work around.

Herb

Hi Dilip,
if you just want to "see" the data, you can always use a report ..

Ciao
Fabio

Hi Herb

I agree with you. But, If more than 256 columns are not required, why SqlServer and Oracle are support 1024 columns ?
as you said, if we want to use more than 256 columns to use, depend on SqlServer/Oracle/etc., . That means Lianja database is backward comparing to other RDBMS?

So, as like VFP we have to consider Lianja also as a front-end tool only?. if we want to compete in market, we should not tell excuses. the same question may raise many others after considering lianja.

I don't want Lianja Database to be backward because of this reason.

Thanks,
Dilip

Hi Dilip,

I guess it would depend on what your needs are.
For example, SQL Server and Oracle are Relational Database Management systems.

Lianja is an entire framework. From local or remote databases and tables, to JavaScript web pages, to mobile app development to robust desktop apps that easily combine VFP, Python, PHP, Javascript, TypeScript, C and C++.

How many applications need 1000 columns in a single table? I can see some data analytics possibly designed that way.

If you look on the Roadmap, at Lianja SQL Server 6.0 release (Codenamed JackalDB), there will be a Major upgrade to the Lianja SQL Server.
It may very well be that in that release the columns limit may be larger.
If this is something that is critical, you can submit an Enhancement Request and the Lianja team will definitely evaluate it.

They may pass on it, but you can submit it.

Herb

Hi Dilip,

If you want to compete in the market, you have to use best practices. And best practice is to make your database into Fourth Normal Form, at least. Assuming you have covered normalization in your studies, you will be aware of the tradeoffs between speed and clarity that play into the decision whether to go all the way to Fifth Normal Form.

There is an economic side to using best practices: for the past 20 years the figure I have seen is that 60% of development costs are maintenance, not implementation. As I have told clients for that same amount of time, I will not help you hurt yourself economically by showing you how to use a poorly designed database. I am surprised no one at your company is looking at this issue from that perspective.

The Lianja database is very standard in its capabilities except in the areas where it outshines every other database on the market. I am referring the its use of oData for "diff's," and the ability to inspect and modify this diff to meet particular USE CASE's; and its separation of concerns by having metadata follow the data, rather than having it reside in code.

My offer to work with you, here on the forum, in seeing what clarity might be achieved by redesigning a large-column-count table, still stands. Perhaps seeing what would be gained would convince your fellow workers. Or perhaps I'll be convinced it makes sense for that table to be designed the way it is. We'll never know until we do it. All the rest is pointless speculation.

But of course if those at your company insist on maintaining bad practices regardless of evidence, then you have no choice. I realize you might have no control over this. There are always times in life when we have to "grin and bear it."

Hank

Thanks Herb
that's true

Hi Hank,

yes, I have no control to redesign the database. but i can insist to migrate

Thanks,
Dilip