network performance?

[hi there]

hi everyone,

after reading the bazillion posts on database splitting i still have a couple of questions i was hoping someone could help me with. is the main advantage of .MDB database splitting data stability/integrity? does the amount data you save from going across the network (forms, reports, DAPs) when you have the FE on the individual's workstation pale in comparison to the data required to be sent across the network when running queries on the user's FE? i'm trying to figure out whether i should convert some of my split MDB databases to ADP projects and was wondering what are the network performance advantages to doing this? if there are advantages are they significant?

thanks

 

[Calvin]

Wow, simple questions, not simple answers, but I will give it a go.

is the main advantage of .MDB database splitting data stability/integrity?

No, I wouldn't say so. I would have to say it is Deployability. The advantage being that your data (the Backend) is located in a central location either a shared folder on a server or located on an SQL Server that everyone can access through varying degree's of security, and your Forms, Reports and supporting code (the Frontend) is compiled as an MDE and is distributed to the clients workstations. As you improve and make changes to the Frontend by adding features, forms, reports, and fixing bugs, you can compile new versions and distrubute it without disrupting your Backend database.

does the amount data you save from going across the network (forms, reports, DAPs) when you have the FE on the individual's workstation pale in comparison to the data required to be sent across the network when running queries on the user's FE? i'm trying to figure out whether i should convert some of my split MDB databases to ADP projects and was wondering what are the network performance advantages to doing this?

1. If you are using an MDB/E frontend located on the clients workstaion connected to an MDB backend located somewhere else on the network, and your run a query on the client ALL of the data from the related tables has to be transmitted accross teh network before the query can evaluate what needs to be displayed to the user. ie. a table with 100k records has to transmit all 100k for the query to evaluate and determine that only 4k need to be displayed.
2. If you are using an ADP/E frontend located on the clients workstation connect to an SQL database on a server somewhere, and the query in example one above has been converted to a View to be run on the server, the server will evaluate the 100k records of data locally and transmit only the 4k records across network to the client, greatly speeding up the process and dramatically reducing communications clout on the network.
Also an ADP/E project will have far more stable communication/connection with the database because of the ADO connection technology as opposed to the ODBC connection that you will have to use with an MDB/E.

if there are advantages are they significant?

Yes, very significant, ADP over MDB is connection stability, reliability, security, speed, some ability to editing SQL server database properties without the need for using Enterprise Manager, and much more.

 

[hi there]

wow. thanks calvin. those were great explainations. i especially appreciate your description of where each application resides. one of things i was confused about was do you distribute an ADP project the same way you distribute a file-server jet application. this client/server stuff fries my brain (ODBC, OLE DB, pass through queries,...etc) ahhhhhh. again thanks a lot for the reply it was very helpful.