Solved

speed up a split DB

Posted on 2000-02-16
45
421 Views
Last Modified: 2008-03-17
What methods can I take to speed up a recently split multiuser Access 97 DB? I have combo boxes in a form (on local PC) that call a table (on shared server) and it's really sllloooowwww. Get the idea? What can I do to speed this and any other processes up? ANy general tip can help. Thanks.

powermixx.
0
Comment
Question by:powermixx
  • 16
  • 9
  • 9
  • +4
45 Comments
 
LVL 10

Expert Comment

by:paasky
Comment Utility
Hello powermixx,

Have you analyzed database performance with any tool? You might get some info about bottlenecks using Access Performance Wizard: select Tools - Analyze - Performance.

There are also commercial analyze tools for Access with lots of extra features.

Regards,
Paasky
0
 
LVL 1

Expert Comment

by:SeanGraflund
Comment Utility
powermixx,

Most of the time a linked table on a Database is really slow when it's over a network connection.  I used to have 5 spearate databases .. and linked tables to each one .. and god was it slow.

What I ended up doing was combining them all into one large database.  I'm now working on integrating the data so it uses one main customer table instead of a different main customer table for each database.

From there, I just have a main switchboard that selects between the databases the user wants to enter.  Thus also alleviating all the pain of having multiple databases open on the same PC.

But there really isn't a way I don't think to speed up performance over a network, unless you move the Database to a different File server that has less traffic.
0
 
LVL 6

Expert Comment

by:simonbennett
Comment Utility
You have several options, all of which have pro's cons.

1)Use a separate local db. Not really used for access -> access but may be worth a try. When each user logs on, you copy all the 'static' data to the front end db on their machine. Hey presto, less network usage. On the minus side you can suffer from out of synch databases.

2)Use Memory. Similar to the above. When you open the client db, open all relevant recordsets for combo boxes as snapshots. When you need the combo, populate the list from the snapshot. Cons are same as the above, and slightly more coding.

3)Upgrade - move to a 'proper' server based database which is designed to work over a network. Probably too much hassle at this stage, but bear it in mind for version 2.

4)Optimisation. Do you have a good indexing policy? DO you compact your db regularly? Have you thought of opening the forms invisible (Forms("<FormName>").visible = false) instead of using docmd.openform each time?

5) Replication. Probably not practicle - especially if you have a simple network with few segments and you need a replica for each user, but none the less an option.

Good Luck

Simon
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
One other suggestion. I inherited an application that had combo boxes that tokk over 10 seconds to open. The problem there was that the record source of the combo box was not a stored query but was a SQL string. When you don't use a stored query then when Access compiles the SQL string it tries to optimize the query. This optimization process requests lots of info about the table structures and so you get a lot of network traffic back and forth bewteen access and the server during the compilation process. If the network is slow you get slow combo box performance. simply be setting the source of the combo box to a stored query (even thought it was a parameter query) we went from 10 secs to under .5 secs for the box to open.
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
One other suggestion. I inherited an application that had combo boxes that tokk over 10 seconds to open. The problem there was that the record source of the combo box was not a stored query but was a SQL string. When you don't use a stored query then when Access compiles the SQL string it tries to optimize the query. This optimization process requests lots of info about the table structures and so you get a lot of network traffic back and forth bewteen access and the server during the compilation process. If the network is slow you get slow combo box performance. simply be setting the source of the combo box to a stored query (even thought it was a parameter query) we went from 10 secs to under .5 secs for the box to open.
0
 

Author Comment

by:powermixx
Comment Utility
fedsuns,

How do I set the source of the combo boxes to a stored query?
0
 
LVL 4

Expert Comment

by:wesleystewart
Comment Utility
I'd go with Simonbennet's suggestion number 1.  When we went to a local front-end/network back-end setup it boosted performance quite a bit.

Optimize, Optimize, Optimize.  Make sure the table that your combo box is hitting is indexed properly (trial and error is the only way to tell) and, like fedsuns comments, use stored queries as often as possible.

Wes
0
 

Author Comment

by:powermixx
Comment Utility
Simon,

What do you mean..."use a separate locl DB. The current DB is a split, shared DB. I can not have duplicate DB's with duplicate data on several PC's. Is that what your recommending? Sorry, I'm just a little confused by your suggestion.
0
 
LVL 4

Expert Comment

by:wesleystewart
Comment Utility
Generate a .mdb file that contains all the forms, modules, queries, etc.  Put this .mdb on each user's machine.  From this "front-end" .mdb file, link to the tables that have the data, which will reside on the server.

Often you can put commonly-used, static data in a table in the front-end.  Accessing it is much faster and it cuts down on the network traffic.

Data like Products, States, Names of employees, etc, might meet this description.  This can reside on the front-end .mdb.  More dynamic data, like order information, inventory levels, etc, can reside in the "data" .mdb.

Wes
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
Powermixx,
    In the properties box of the the combo box in question select control source and hit the down arrow. A list of tables and queries should appear. Choose the query that you wish to fill the box. As an aside simon's and wesly stewarts suggestion are really good ones.
0
 
LVL 10

Expert Comment

by:paasky
Comment Utility
powermixx,

Stored queries are actually Access queries in your database project. If you set combobox RowSource as Query for eg. "Query_Products" instead of "SELECT Product_ID, Product_Name from Products;" it works much faster.

When you run Database Performance Analyze, it recommends you to create queries for record/rowsources where you haven't used stored queries.

Paasky
0
 

Author Comment

by:powermixx
Comment Utility
Adjusted points to 75
0
 

Author Comment

by:powermixx
Comment Utility
Okay all,

As a test, I changed my "record source" for one of my combo boxes to a query that is located on my local PC. IT IS JUST AS SLOW as the linked table! The table only has one field in it and it's indexed. What else can I do?

I do have the DB split. The "front-end" is on local users PC's and the "back-end" is on the server. At present the tables are part of the "back-end" DB because the data in those tables changes, not every day, but it does change. Is there a method of updating (or copying) the data in the shared DB tables to the local PC's? Can this be done by the indivual users by a command button so the data in everyone's "front-end" Db is consistant?
0
 
LVL 10

Expert Comment

by:paasky
Comment Utility
powermixx, the stored queries should run faster after compilation (this is done by running and saving them in query design view - was that right?).

If you're using lookup tables which data doesn't change all the time, you could make a copy of them into local PC in application startup and use them in your form's comboboxes instead.

Paasky
0
 
LVL 4

Expert Comment

by:wesleystewart
Comment Utility
How many records are in the datasource for your combo box and how many of them are returned (fit the criteria)

Wes
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
powermixx,
     As passkey aluded to the query should be run  once to compile it (if that didn't happen then opening up the combo box would have done it and the second time the combo box is opened it should go "fast"). I suspect you probably have all ready done that so the question comes as to what next. Please forgive me for asking what is perhaps an obvious question but in the code is the source of the combo box being set to a SQL string? This would override the record source setting you made in design mode. Wesley has a good question that may also help to pinpoint the problem. Thanks and please keep me informed. Oh by the way does the query by itself (outside of the combo box) run slowly?
John Smith
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
Powermixx,

  Try this out and see if it helps.  In the front end MDB stored on the local PC, declare a global level recordset variable and open a recordset with it against one of the tables in the backend MDB on the server as soon as you app starts up.  Close this when the app closes.

  What this does is force Access to keep a link to the backend open all the time, thus reducing the amount of time spent dealing with the .LDB file.  Along these same lines, if this is a NT server, you might want to try turning off optimistic locking.

  All of the others have made great suggestions, but now where did I see anyone ask how many combo's there are and how big they were.  If were talking 2 or 3 with a 100 or so lines that is fine.  But if you have 10 or 15 parked on a form or one that has thousands of rows, that's a problem.

  Also, the comment about SQL strings being used in place of stored queries is incorrect.  A97 stores all SQL strings used in combos as temp queries (loop through the querydef collection and you'll see a lot that start with ~ - these are the temp queries) as a performance enhancement.  

  And last, a lot more detail would help. ie.

# Clients,
Types of clients and amount of memory,
Type of server (NT or Novell),
Are you using the default JET settings?
etc.

  Bottom line is that it's a whole different world when you go to the file server setup.

JimD.
0
 
LVL 10

Expert Comment

by:paasky
Comment Utility
JDettman,

if that, what you say about Queries against Select strings is true then I have to blaim MS for giving me (us?) wrong information. When I run Access performance analyzer it recommends to use stored queries just for performance issues.

I have to admit I don't have that much experience of using split Access databases that I could not say which argument is true (I am working with Oracle and other SQL products - and using Access only as a client).

This thread has been very informative, thank you all.

Best regards,
Paasky
0
 
LVL 4

Expert Comment

by:wesleystewart
Comment Utility
To create the temp query doesn't it have to look at the SQL and decide how to optimize it?  That's the performance hit you avoid by using stored queries.

Wes
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
Wesley, powermixx and JDettman,
    I believe Wes is right about the temp queries. I have on a number of occassions replaced SQL strings in combo boxes with stored queries and it always seems to speed things up. (note I think that the storage of SQL strings as temp queries makes the second or third time you open the box run faster since at that point the query is all ready stored) Of course maybe I don't understand what I am doing but I think on this one Wes is correct. Powermixx as both Wes and jdettman have talked about it would be interesting to know just how many records there are in your combo box and whether the query runs slowly outside of the combobox. Just to slake my own curiosity I'd really like to understnad the nature of your performance issues better. Thanks
John Smith
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
Guys,

  I positive about the temp queries and will lookup the reference as soon as I get a chance.  But if you want to try it for yourself<g>, do the following:

1. Create a new MDB.
2. Place the following code in a module:
Function DoAllQueryDefs()

    Dim db As DATABASE
    Dim myQueryDef As QueryDef
    Dim intI As Integer

    Set db = DBEngine.Workspaces(0).Databases(0)

    For intI = 0 To db.QueryDefs.Count - 1
        Set myQueryDef = db.QueryDefs(intI)
        Debug.Print "> "; myQueryDef.Name

    Next intI

End Function

3. Run the function from the debug window.  You'll find nothing prints.
4. Now create a new table with a couple of fields and add a few records.
5. Then create a form with a single combo (unbound) using the table from step 4 as a rowsource via an SQL statement.  
6. Run the form, then close it.
7. Now run the above function again.  You'll see something like this in the debug window:

debug.? doallquerydefs()
> ~sq_cForm1~sq_cCombo0

  The change was made in A95 to combat the slow combo performance in A2.  MSFT found that lots of developers were using SQL strings in combo's and thus not reaping the benefits of a stored query, so they started saving the optimize plan for SQL statements in combos as temp queries (query def's that start with a ~).

  However if the SQL statement has parameters, I don't believe it's saved. Since there is no way to know what the parmeters may be, saving the query plan before hand does you no good as it may not be the most efficent plan.  So performance may suffer if you use stored queries when parameters are involved.

JimD.
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
JDettman
Hi JimD. Thanks for you code. I tried the code you suggested and all I got were the names of the queries I had all ready constructed, and no queries that began with ~. I am using AC97. I did tell it to show hidden and system objects. Is there something else I should have done? Is there some option someplace that needs to be checked? I constructed the combo boxes with the combobox wizard and did in fact check to make sure that there is a SQL string in the box. So I don't know SQL statements with parameters I think are saved since I have used saved parameter queries and picked up performance, but I could be wrong.
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
fedsuns,

 You didn't follow the directions<g>.  

Start with a new MDB to make it eaiser to see the created query.

  Make sure you run the form and then save it.

  The hidden/system object flags do not make a difference.

JimD.

0
 

Author Comment

by:powermixx
Comment Utility
I have tried a couple of methods to speed up my combos:

1) I moved some of the tables to the "front-end" DB (BTW, these tables are relatively small - at most, one of the tables has 60 records. So their small tables.) After moving the tables, response is extremely fast of course. Problem is - how can multiple users update or add new entries to this combo box when there are now several instances of the referenced table on many PC's?

2) With the tables on the "back-end" DB (on the server), I created a query on the "front-end" PC and pointed the combo box to that query. It is just as slow as a linked table. The benefit here is that the data is always up-to-date (Not several versions of the table as the above method). Problem is - It's still very slow. I did open the query in design view and save it. Shouldn't that optimize the query? The only thing I notice is that the combo box is fast the second time I click it. But I have no reason to click it twice in one form! So, any ideas? Am I going about figuring this out the right way?

Thanks for all of the great input. It really shows there are people willing to help. I appreciate it.

powermixx.
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
thanks jim but I started with a new db I ran the form and did save it. Would you like me to send it to you? You really have me curious now.
Wesley do you know what I am doing wrong so that I can't get the temporary queries that Jim evidently sees?
 Powermixx I don't believe just opening the quey in design mode and then saving it recompiles it. I believe you have to run the query once or compact the database to run the optimization. Once the query is run though it is compiled.
0
 
LVL 4

Expert Comment

by:wesleystewart
Comment Utility
The code looks sound.  Can you step through the code and run the code above right after the sql is executed?

Wes
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
I apologize,
Now it works. Evidently I hadn't closed and or saved the forms first. Thanks for you patience guys.
John Smith
0
 

Author Comment

by:powermixx
Comment Utility
I have tried a couple of methods to speed up my combos:

                    1) I moved some of the tables to the "front-end" DB (BTW, these tables are relatively small - at most, one of the tables has 60 records. So their small tables.) After
                    moving the tables, response is extremely fast of course. Problem is - how can multiple users update or add new entries to this combo box when there are now several
                    instances of the referenced table on many PC's?

                    2) With the tables on the "back-end" DB (on the server), I created a query on the "front-end" PC and pointed the combo box to that query. It is just as slow as a linked
                    table. The benefit here is that the data is always up-to-date (Not several versions of the table as the above method). Problem is - It's still very slow. I did open the query in
                    design view and save it. Shouldn't that optimize the query? The only thing I notice is that the combo box is fast the second time I click it. But I have no reason to click it
                    twice in one form! So, any ideas? Am I going about figuring this out the right way?

                    Thanks for all of the great input. It really shows there are people willing to help. I appreciate it.

                    powermixx.
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
Powermix,

  Reason it's slow on the first click is that it has not been fully populated with data.

  Second time around, everything is in the local cache so it's fast.

  Let's get down to some details:

1. How many combo's are on this form?
2. For this combo that you mentioned, how many rows does it have?
3. Number of columns?
4. Is the bound column hidden?
5. Is the bound column text or numeric?
6. What do you consider slow? 2 seconds, 5 seconds, etc.
7. What type of network are we running on (peer to peer or file server, Novell or NT)?
8. What speed is your network 10Mb or 100 Mb?

Depending on the questions to these answers, I can give you some tips and tricks to speed things up.

JimD.
0
 

Author Comment

by:powermixx
Comment Utility
Thanks JimD.

I have 6 combo boxes on the form. All have one column. Most only have 10 rows. One of the combos has 50 or so rows. All combo are slow - 5 seconds or more. All combos are text fields.

We have a NT server (NTFS) network at 100Mb (I think).

Someone earlier suggested making forms invisible instead of opening/closing all the time. Is this good advice?

Is the bound column hidden?<--- I do not know. Where can I find this out?

Thanks!
pmx
0
 

Author Comment

by:powermixx
Comment Utility
Any ideas JimD?
0
 
LVL 1

Expert Comment

by:fedsuns
Comment Utility
powermixx,
    Just out of curiosity are the queries that fill these boxes group by queries? And do the queries by themselves runslowly? Thanks
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
PowerMix,

  OK, something is really wrong then.  With 6 combo's, 1 column each, and no more then 50 rows, they sould not be taking 5 seconds each.

  First, open up a module and do a compile save/all.  Then run the form.  Any improvement?

  Next, if you could post the SQL for one of the combo's, I'd like to look at it.  Also for the combo, what do you have for the following properties:

Control Source
Row Source
Column Count
Column Widths
Bound Column
Limit To List
Auto Expand

  Also, besides the combo's, what in general are you doing with this form?

<<We have a NT server (NTFS) network at 100Mb (I think).>>

  Should be plenty fast enough, but how many users?

<<Someone earlier suggested making forms invisible instead of opening/closing all the time. Is this good advice?>>

  Yes and no.  Yes, in that once the app gets going, everything is really fast because it's already loaded.  No in that depending on the type of app, it may consume too many resources.

  If you have an app with only a dozen or so forms that are not all that complicated, then it might make sense to do this.  But I generally don't for a couple of reasons:

1.  Apps always get more complex, never simpler.  You may find yourself at a dead end at some point in the future.

2.  User may park on a single form for most of the day, but they pay a penalty every time they start the app when every form gets loaded.

3.  start up time can become significant.

  I have found over the years that loading every form at startup is not generally a good idea.  I perfer to focus on performance through other means.

<<Is the bound column hidden?<--- I do not know. Where can I find this out? >>

  If the combo's are only a single column, then the bound column cannot be hidden.  Since you only have one column, it must be displayed.

JimD.


0
 

Author Comment

by:powermixx
Comment Utility
Adjusted points to 100
0
 

Author Comment

by:powermixx
Comment Utility
Here's how I access my data.

I have a form (which acts like a switchboard) with command buttons on it. I click the command button and a "Enter Parameter Value" box appears. I type in the record number I'm looking for and it displays a form with the required fields. It's taking about 8 seconds for the "Enter Parameter Value" (query prompt) to appear. Then it's another 5-8 seconds for the actual record to appear. zzzzzzz. This seems like a basic approach to finding records for data entry. Is there a more appropriate/faster way? I have read the "help" files for optimizing tables, queries, combo boxes, but I haven't had much results in increasing speeds.

The query is a select query (in the front end DB) referencing one table (in the back end DB) which has about 19000 records in it. And yes, since I split the DB, the query runs slow by itself.

Seeing the hourglass in my sleep,
powermixx
0
 

Author Comment

by:powermixx
Comment Utility
JimD,

I apologize. I'm mixing up a slow query and a slow combo box. I'll start from the top. First, as noted in previous post, the (front end) query itself is slow. Now; on the form, the combo boxes are slow as well.

Here's the "select query" criteria for the form in discussion:

Like [Enter the Log Number]
(BTW, even loading the query design takes about 5 seconds.)

Form Properties:

Control Source     AName (field on my "Main Table")
Row Source     Select [WName]  From [WTable] ORDER BY [WName];
Column Count 1
Column Width 1.7"
Bound Column 1
Limit to List YES (I know this may be slowing things, but, I need this so others can not accidently create more names.)
Auto Expand YES (I know this may be slowing things, but, this help so the user doesn't have to enter the whole text string.)

And I was incorrect. It's taking exactly 2 seconds for the combo to be populated. That's marginally acceptable. So I think my greater concern may be the query loading itself. Hope this helps.



0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
It sounds like the app is in an uncompiled state and is slow in general.  Try the following:

1. Compact the backend MDB.
2. In the front end, open the query, execute it, and make sure you save it.
3. Open a module in design view, then click Debug on the menubar and select "Compile/Save All".

Any improvement?

  Also, make sure you have an index on the field that the parameter is being used against and on WName.  Make sure you use the = operator instead of LIKE.  Do these changes before doing the steps above.

JimD.

 
0
 

Author Comment

by:powermixx
Comment Utility
JDettman,

Okay, after doing as you suggested above, I DO see improvement. After compiling modules, making sure field is indexed, switched "Like" with "=" in query, the query is a little faster.

DETAIL:
1) Press the command button on my form. I still wait 5, 7, even 33 seconds once!
2) Once the "Enter Event Parameter" box appears, I enter my criteria and here's where I see improvement. The query opens the form in 2 or less seconds. That's a big improvement.
3) How can I improve the time waiting for the "Enter Event Parameter" box to appear?

Thank you for your contined acureate support.

powermixx
0
 

Author Comment

by:powermixx
Comment Utility
JDettman,

Okay, after doing as you suggested above, I DO see improvement. After compiling modules, making sure field is indexed, switched "Like" with "=" in query, the query is a little faster.

DETAIL:
1) Press the command button on my form. I still wait 5, 7, even 33 seconds once!
2) Once the "Enter Event Parameter" box appears, I enter my criteria and here's where I see improvement. The query opens the form in 2 or less seconds. That's a big improvement.
3) How can I improve the time waiting for the "Enter Event Parameter" box to appear?

Thank you for your continued accurate support.

powermixx
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
Is the database small?  If so, you can E-Mail it to me if you wish and I'll have a quick look.  This will save a lot of time going back and forth (don't know if your under any kind of a dead line to get this done).

Even if you can just E-mail that single form in a database on it's own, it would help.

JimD.
0
 
LVL 57

Accepted Solution

by:
Jim Dettman (Microsoft MVP/ EE MVE) earned 100 total points
Comment Utility
Ah just tought of something else...you do have Access installed locally on the client correct?  If not, your not only pulling the data over, put the actual Access code.  This could account for the big delay.

JimD.
0
 

Author Comment

by:powermixx
Comment Utility
DB is 12 Meg. And for each account, there's permissions and code needed for startup.
I DO have the app loaded on my (client) local PC.

Again,

The query prompt is still taking 5 sec. or more.
The command button points to a locally stored query which points to a linked table. Hope this helps.

pmx
0
 
LVL 57

Expert Comment

by:Jim Dettman (Microsoft MVP/ EE MVE)
Comment Utility
pmx,

  When you say the "app" is loaded on your pc, do you mean your application, Access, or both.

 Being that it's 12MB, just shove the form, query that it's based on, and the empty table(s) into a MDB and send it along.

  I think your answer is going to be a little code work (use of the seek method) to find the record for the form, but I need to get an overall feel for what your trying to do.  As you have discovered, with some problems you can go through a lot of questions and answers and not get to the bottom of things.

  If you don't want to send it for some reason, that's fine to, we can just keep working as we are.

JimD.
0
 

Author Comment

by:powermixx
Comment Utility
JimD,
Let me get thru this weekend and I'll return to this question and try to close this thing out. Work is so busy I can't address this right now, but your support is appreciated. I'll post more early next week. My apologies.

powermixx.
0
 

Author Comment

by:powermixx
Comment Utility
Your help did in fact improve speed on my shared DB. I just want to close this Q. I still need to address the issue of data that changes often - how/where is the best place (locally or shared) to store and update the data. But I'll have to wait on it for now because I'm soooo busy!! Thanks JD.

powermixx.
0

Featured Post

Get up to 2TB FREE CLOUD per backup license!

An exclusive Black Friday offer just for Expert Exchange audience! Buy any of our top-rated backup solutions & get up to 2TB free cloud per system! Perform local & cloud backup in the same step, and restore instantly—anytime, anywhere. Grab this deal now before it disappears!

Join & Write a Comment

In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
In a multiple monitor setup, if you don't want to use AutoCenter to position your popup forms, you have a problem: where will they appear?  Sometimes you may have an additional problem: where the devil did they go?  If you last had a popup form open…
Familiarize people with the process of utilizing SQL Server views from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Access…
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now