Announcement

**csda1** · 03-31-2002, 07:58 AM

RE: WAN/Virtual LAN possibilities?

Bill,

Until Alpha Software provides a true client-server version (A5V6), you can not realistically operate A5 directly over a WAN (or even a slow LAN network). You must operate on a system that has fast access to the server. This can only be done by remote programs (like PCAnywhere) that require a host computer, or by something like either a Citrix server that provides virtual machines that operate sort of like PCAnywhere. Win 2000 has a stripped down version of Citrix called Terminal Services that will also work.

Of course, in either case, you should be running network optimized as well.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**EYoo** · 03-31-2002, 02:54 PM

RE: WAN/Virtual LAN possibilities?

bill,

I am currently working on a project for a client to connect two LANs via VPN (Asia and Los Angeles). As I do not personally have the expertise, I have outsourced the VPN task. I too am waiting to see the result of this implementation.

I am developing under A5V4.5 and will be using the runtime version with network optimization on each work station (8 users in Asia and about 10 users in LA) - the data will reside on a server in LA (Win2000).

We are schedule for the first test in late April / early May. I won't know the result until then. If the "real-time" mode is not possible due to the network traffic (or other considerations), then we will implement the batch mode option.

By all indications, the speed should not be a problem - the tasks involved are mainly look-up functions of data entered at each location by the other. A challenge is that I have records that requires date/time stamping and due to the time difference I will have to make sure the difference is properly managed.

I will let you know as to our implementation.

Eugene Yoo

I will update you as the project progress.

**Bill Harriff** · 03-31-2002, 03:20 PM

RE: WAN/Virtual LAN possibilities?

Ira,

Our current PCAnywhere connections run from 56K (42-48kbps really) up to around 256/384kbps and are barely tolerable and tie-up 1 machine at the main plant. Why wouldn't it work at least that well via a virtual LAN? The Netware server would see these connections as local users so if they authenticate as legitimate users they get access to the dataset. With the A5 Runtime on these systems from the remote sites they should be able to open the app, right? A5 has no way of determining where the user is connecting from - it is just another "local" user on a virtual LAN. If we run it as P2P and not take the connection thru the server the same is still true. I've got another client with stores in both CA & OR running Peachtree doing this and tho slooooow it works. Why wouldn't A5?

We can buy a faster DSL connection at all sites now and I think they'll do that if the app will work with this setup. If the app is optimized for networking I'd think it'd run it as fast as PCAnywhere at 56k does (I'm aware that PCAW doesn't send the entire screen, just what changes), esp. if we can get it up to a 1mbps connection.

I'd still like to know if anyone is doing a remote connection at these kinds of speeds, esp. if they're doing via vpn. Eugene Yoo's post is strikingly similar to what I'm proposing - it'll be interesting to see if others are trying/are getting A5 to work under this type of setup.

Bill

**csda1** · 03-31-2002, 05:26 PM

RE: WAN/Virtual LAN possibilities?

Bill,

A5 will work through a slow network (no matter how arranged), but for proper speed operation, the network should be 100 Mbps. You're talking 5 Mbps or less. This affects all shared accesses of records and saving of records.

The very nature of non-true client server databases requires all negotiation for access and locks on records be performed in a sequential manner, and since all systems wait during this negotiation, the speed of the entire system is gated by this. By placing all instances of A5 running on a fast LAN, or a virtual fast LAN (by placing the database server and Citrix servers in the same system), this negotiation is not a significant limitation.

It takes only 1 system not on the fast LAN to slow the entire shared operation down to a crawl each and every time it accesses a record.

The speed between a Host and a remote PCAnywhere or Terminal Server has no affect on speed, just on how fast the screen is updated to reflect changes to the host's screen.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**Ray Fernandez** · 03-31-2002, 08:57 PM

RE: WAN/Virtual LAN possibilities?

Yes, it is true, that all non-client server databases will perform on a sequential row-by-row manner, however this is not the main reason why accessing information from a VPN would be quite slow. The main reason is the amount of traffic that is created when any requests are made to the database engine, in this case, I believe codebase is the engine A5 is using.

If your tables are quite small, this of course consisting of the amount of row and columns, in A5 terms, the amount of fields and records in the table, the amount of network traffic is reduced and the speed is quite acceptable. Of course, this changes significantly once a table starts to grow. Also the fact that you are accessing tables link to other tables and in turn have those records in the child table being transmitted across the wire.

The main problem with the non client-server backends, is that there is no way to limit the return record set count. So of course if you need only one record from a table that has over 100,000 rows (records), then 100,000 records will be transmitted across the wire to view or modified, even if only one record is needed and then to send back 100,000 records, creating of course, a very large traffic jam, and probably even worse than the traffic jams here in Miami.

And like Ira said, a lock here, a lock there, everywhere a lock lock.

This is one of the main reasons why this type of locking is not used in client-server. In fact, 2, 4 or 100 people can be in edit mode on the same row (record). It's up to the programmer to anticipate this in a client server environment.

While it is possible TODAY to submit SQL statements against both A5 & A4 tables, there is no way to limit the amount of records being returned, even with Microsoft ADO components.

However there is a way TODAY just to retrieve information from any A5 or A4 table structure through the Internet, without going client-server. This is done using Crystal Reports, placing Crystal Reports Server on the same network as your Alpha tables and running Crystal queries through a browser. There is an option in Crystal were you tell it that all queries are to be performed at the server level. This will mimic the client server structure. I've been telling people for very long time Crystal Reports is one of these tools that every developer needs to know about. Very easy to use and extremely powerful.

Eugene, Good luck with your VPN.

RF - ARS Motorola

**DiFaz** · 03-31-2002, 10:49 PM

RE: WAN/Virtual LAN possibilities?

Eugene,

I suggest you take a look at either Citrix, or Microsoft's Terminal Server which uses the Citrix engine. I have a client running a realtime WAN, using Terminal Server, and the throughput is truly amazing. Be aware though that their locations are geographically very close. I suspect a connection from LA to Asia would be noticeably slower, but still workable. Especially if you have a fast (Terminal) server with a lot of RAM, and a fast internet connection.

Ray DiFazio

**csda1** · 04-01-2002, 03:52 AM

RE: WAN/Virtual LAN possibilities?

Ray,

The size of the tables (the number of records) is almost irrelvant unless you are constantly running searches, queries and reports that do not use LQO (Lightning Query Optimization). If you are, then you have created a very inefficient application design. The actual number of records accessed by all users (the parent and all it's children, the number of rows shown in the browse, the records accessed to evaluate a filter -- as opposed to using an index to minimize the access -- that's what LQO does, all of these are record accesses) and how simultaneously is what affects lcoking speed.

A true client server does all of the negotiation itself, and the workstations just make requests. In many respects it is not much different than Citrix and the database running on the same server.

The number of fields has almost no bearing on speed.

Also, if your network bandwidth is overloaded for any reason (including loading forms and applications over the network rather than using them on the local machine in network optimization), then this also will create a tremendous slowdown in running an application.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**Ray Fernandez** · 04-01-2002, 05:56 AM

RE: WAN/Virtual LAN possibilities?

Ira,

It has been a while since we didn't see head-to-head on something.

I respectfully disagree with your statements, UNLESS (LQO) mimics client-server, it doesn't matter if you are using indexes or filters. All the records are download and then your client machine will filter or run you queries at the local level. Just because you see only 1 record on the screen on your local computer don't think that the rest of your records are not there. This can be very easily proven by pointing (not even opening, just pointing) to a very large table and doing a filter on just one record, just time that and see how long it takes. When we did this almost half a year ago with ADO, it took over four minutes to download a 100,000 row table just for a single record, over the wire. - The SQL statement was being monitored and logged by executing a trace over the wire.

I did not use LQO since there no way to get this to work with ADO.

Unless LQO executes on the server itself, I stand by my statements. A table size is measured by both rows and columns, so yes, the number of fields does indeed affect speed, not sure what you would conclude otherwise.

Again unless LQO truly execute ONLY at the server level, only then can the return record set count be controlled. If this is the case then Alpha has created a poor man client-server and my statements are incorrect.

Hope all is well.

RF � ARS Motorola

**csda1** · 04-01-2002, 06:44 AM

RE: WAN/Virtual LAN possibilities?

Ray (Fernandez),

Disable any filters (except index filters used in Index definitions). Then select any index and do a find on a form. 1 and only 1 record will be accessed upon doing the find. It will be essentially instantaneous, no matter how large your tables are. Turning on filters whose expressions are not written to take advantage of LQO (for all intents, LQO is merely an automatic setting of a range in A5), will force reading of every record to evaluate the filter.

There are other ways to accomplish the same speed as LQO using properly formed indexes and other techniques that minimized the records that need to be accessed.
In any large application (many users or many records being accessed), this is the reason that an end user typically get's into trouble and the reason careful design is required. A consultant that is well versed in "proper" techniques like these can save much waiting.

I have covered some of these techniques in other threads, but only a few have taken them to heart. I'm sure Ray DiFazio who has brought me in problem projects of his and John Zaleski will be 2 of many to tell you that what I'm saying is not just smoke and mirrors, but in fact reality.

Peter Wayne has often said to use a minimum of indexes necessary, and I'll basically agree with that. Some people take that too much to heart, and have no indexes. I would say instead, that one should have as many indexes as required to minimize record accesses on a peak (particualarly peak) as well as average basis.

Indexes add only overhead at record save time (and at index rebuild time, something my applications almost never have had to do.)

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**csda1** · 04-01-2002, 06:55 AM

RE: WAN/Virtual LAN possibilities?

Ray (Fernandez),

One other thing.

Using ADO (or ODBC) drivers with SQL, would probably necessitate reading every record to apply a filter. ODBC drivers probably do not have a way to use any filter expression of A5, and thus may be stuck to sending all records to A5 for processing.

If you are using A5 in this manner, a Citrix server running A5 with the database on the same system, would probably be the equivalent of running a LAN at the speed of the internal PCI bus (approximately equivalent to a 1.5Gbps LAN)

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**Ray Fernandez** · 04-01-2002, 07:51 AM

RE: WAN/Virtual LAN possibilities?

Ira,

Yes, I understand what you are saying, but are we talking about the same things here.

Are we talking about A5, a client using VPN to access records at the other end of the wire? (Not using PCAnywhere or Citrix, or Microsoft's Terminal Server). Is so, the way any non client-server system works, Access, Paradox, Codebase � non client-server, FilePro, Alpha 4 & 5, etc. will download all records to the client first and only then will the query or filter take place. There are no indexes ever being use at a client computer across the wire, only at the server � this is how client-server works.

Here's my main point!

1. Again, are the queries or filters being run at the server or client levels?

2. Is they are being run at the server level -will these limit the amount of records going arcoss the wire? If the answerer is yes, they are being limited, them there we be no speed issues.

If the amount of records can not be limit across the wire, then you will have speed issues.

Many Thanks,
RF - ARS Motorola

**csda1** · 04-01-2002, 08:09 AM

RE: WAN/Virtual LAN possibilities?

Ray,

If Alpha 5 (or Alpha 4/FoxPro, dBase III etc for that matter) is accessing it's file format, it is using indexes, no matter what the communication method (VPN, terminal server, Citrix, PC Anywhere) being used is. Where the record negotiation (locking) occurs and the speed of that is the only difference.

By using terminal server, Citrix, PC Anywhere or other remote software, even over a VPN, brings the negotiation closer (and hence faster) to the database/index location. ODBC and ADO using SQL may force evaluation of a filter at the A5 client. Moving these A5 clients closer to the database (again, by using terminal server, Citrix, PC Anywhere or other remote software, or a very fast LAN) will make the speed come close to the true-client server model.

True Client-Server has a slow down issue as well. Server side field rules will be evaluated by the server stealing some percentage of server system speed, whereas non-client server models have the client doing all of the field rule evaluation (which scales linearly with the number of computers). In most cases, the client server model wins out do the relatively higher overhead of the locking process.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

**Ray Fernandez** · 04-01-2002, 08:46 AM

RE: WAN/Virtual LAN possibilities?

Ira,

===
Again it all breakdown to this.

Again, are the queries or filters being run at the server or client levels?

Is they are being run at the server level -will these limit the amount of records going arcoss the wire? If the answerer is yes, they are being limited, them there we be no speed issues.

If the amount of records can not be limit across the wire, then you will have speed issues.

===

You keep talking about locking, there are no locking issues with true client server. (Unless you have 2 or more people on the same row, and even them, only 1 line of code we take care of this). This is all I do. I�ve haven�t work on a non client-server database in over 3 years. There's also no index issues with a true-client server system, at the client level.

Yes, I do understand the locking problems with a non client-server systems and the speed issues, but before you can get a lock, you need to be in edit mode, and before you can go into edit mode, the records need to be download over the wire to the client.

If you ever find you way down here to Miami, we can continue to have this conversation over some good Cuban food. I can probably get Ms. Peake to flip the bill.

Best Regards,
RF � ARS Motorola

**JohnZaleski** · 04-01-2002, 09:22 AM

RE: WAN/Virtual LAN possibilities?

Ray,
You seem to imply that by merely opening a table from a server on a LAN or WAN, the entire table will travel from the server to the local machine. Therefore if I have a form for a table with 1,000,000 records ( 500 bytes each ), the first thing that happens is a 500 meg file gets moved from the server to the local machine ( not to mention the production index that is opened automatically with a table )???? If that were the case, it should be extremely slow to open a very large table, and the difference between opening the same table from a single user machine as opposed to opening it on a LAN would be enormous. I work with large tables and I have not seen that behavior.
I agree with what Ira has said about LQO, but I cannot equate what I've seen with what you describe.I'm talking about working completely within the confines of Alpha ( not using Crystal or other query tools ).
John

Announcement

The Alpha Software Forum Participation Guidelines

WAN/Virtual LAN possibilities?

WAN/Virtual LAN possibilities?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment