Hiding Database Window

[pat_nospam]

I did read about the debugging issue - I'm going to use the Show workaround for that in case of errors. I'll try the Word report method, sounds better anyway because then the users can manipulate the data directly, instead of having to export it (eliminate a step).

One question - once Pop Up and Modal are set to yes and the app is functioning in "preview" mode, it seems a bit more sluggish than without preview mode. Is this common? Does preview mode have to buffer more than regular mode?

Thanks again for all your insight.

Pat

 

[Kevin_S]

Hi Pat -

I haven't personally experienced "sluggishness" but I have heard of people having issues with it before. It has a lot more to do with other factors more than it does with having the access window hidden. Factors such as environment, distribution, "code cleanliness", etc...

If you have the above optimised your performance drop-off should be minimal...

HTH,
Kev

 

[pat_nospam]

Do you think increasing the priority and version of DAO would help?

Just wondering if that code would run faster through DAO.

Thanks again I'll try it on Monday.

 

[Kevin_S]

Increasing the "priority" of DAO over, say , ADO shouldn't effect performance it will only effect which version of VBA will have hierarchy over the other... Try optimising/streamlining your code first as this is usually the culprit.

HTH,
Kev

 

[pat_nospam]

Hmmm - no change. Any ideas on other references that I should increase priority on or make sure are checked?

I suspect that is where my problem is, as the code runs, it just runs slowly.

TIA

 

[Kevin_S]

I suspect that is where my problem is, as the code runs, it just runs slowly.

Again - the problem is not stemming from an unchecked reference (if this was the case the app wouldn't run) and its not stemming from the heirarchy of your priority setting (makes no difference in run speed). The problem lies in your application itself... Make sure you compile your code first as this will increase speed. Also make sure all of your error checks/handling is in place. Next look at your project and look for possible "slow downs". For example - using SQL to generate a query instead of a stored querydef, looping structures that are continuous, bloated BE's or FE's, forms with recordsets based on tables instead of queries (this is a big no-no), etc....

After your check all of these you shouldn't experience the lag difference between the hidden window vs. access window. If you still do then and it is a major problem you may want to rewrite the app in VB to eliminate the problem (if you know VB that is!)

Good Luck,
Kev

 

[pat_nospam]

Kevin -

I spent the morning going through the database checking for the leads you gave me. The code was compiled and the error handling is in place (I had performed all this because of the various programming information from this forum already) I am using stored queries, there aren't any continous loops and the BE is only 15MB while the front end is 4.5MB. There is a compact on close automatically with the FE. However, I DID notice that several of my forms are based on the tables and not queries!

When I updated one of the tables to rely on a query, it functioned MUCH quicker.

My question is, just to make sure I'm doing this correctly and won't cause myself more work. The method I'm using is to simply design new queries based on the tables, so the query basically is a Table.* query. Then I just change the "Record Source" property of the form over to the query instead of the table. Is this correct?

Thanks again for all your help, I've really learned a ton!

 

[Kevin_S]

In a nutshell yes, this is the method you should use. Basing forms on queries and NOT tables is definitely good practice. The reason for this is... performance. When you base a form's recordsource on a table Access, in order to open the form, first spools ALL OF THE RECORDS from the table for use in populating the form. Now this isn't such a big deal when you have a small application on a very fast network with a small number of users BUT if you application is larger and your serving data to tens/hundreds of users over a network with different connection speeds this spooling can be devistating to the load time of forms (Not to mention your network IT staff will want to severely hurt you for the miss use of bandwidth )

So - to solve this problem the best practice method for building forms is to base them on queries with strict WHERE clauses so that you are only viewing/editing/returning a small number of records and, thus, increasing performance. It is much faster for Access to retrive 1-10 records then 10,000 records!!!

The way you set up your forms will work and an increase is seen but the way to get the best performance out of your application is to include Where clauses in your queries (you should see a significant increase in performance from the forms then!)

Also - be weary of the "compile on close" in a multi-user environment as I have seen this result in db corruption in the past. The best method for this is to schedule downtime to go in a manually compact/repair or build it in code to automate this process...

HTH,
Kev

 

[pat_nospam]

Last quick question - everything is running smooth and (most importantly) fast! I love the preview mode and the GUI program feel.

There are a couple of places though where the users usually are able to delete records. Normally they were using the "Edit Menu -> Delete Record" method, but I had been debating adding a "Delete Record" button for some time.

Is there a special key to press to delete a record (an F-key or something), or is my best bet to add the Delete button to the forms?

Thanks again !

Pat

 

[Kevin_S]

You can assign the delete function to special keys so you could do it that way or create a custom menu or or you could create a delete button on eash form... the choice is really up to you. If you want to use special keys seach the forum for "assign value to keys" or something along these lines and check the help files but I think I remember reading something about special keys on the forum a few days ago.

The choice is really yours as the developer on this one as any of these solutions will work just fine...

HTH,
Kev

 

[ghudson]

As an alternative... What about changing the background color of the Access window? I use Stephen Lebans SetMDIBackGround function to color the background color of the Access GUI. I then set my forms to popup modals. Once you hide all toolbars and menu bars your Access application has a very custom and professional look. The attached sample shows you as an example on how easy it is for you to change the color of the Access GUI. I left the menu bar visible so that you can unhide the database window and view database objects. This method is application specific so it does not alter the users Access databases on their PCs. You must run the code to color your Access window each time your application is opened.

HTH

 

[pat_nospam]

Thank you both! Once again, you've been a tremendous help. I do like the different colors in the background, gives it a sharp look

 

[daninthemix]

With the above code, is it possible to have the database visible on the taskbar? As in, Access is hidden but the database itself shows up on the taskbar?

 

[Edwik]

Hi All,

When I put this command:

Private Sub Form_Open(Cancel As Integer)
SetAccessWindow (SW_HIDE)
End Sub

to form Load, its works normally, but I can't see program in my taskbar

 

[agates]

Error Accessing FIle

That is exactly what I am looking for. Ok I tried to do it and it is giving me the error message below.

Error accessing file. Network connection may have been lost.



Open the database. Open Visual Basic Editor and COMPILE the current database. That should fix this issue.

 

[gemma-the-husky]

Although you can hide the database window, users can get it back via the tool bars etc.

If you really want to prevent access to trhe dbs window, you need to change some database properties, and then secure the database, ensuring you remain in the administrator group. You also need to prevent users creating a new database and importing your elements to it.

Even if you compile the dbs to an mde file, you dont hide the dbs window.

Its not trivial

The other thing is that the access tolbar itself gives access to many (often necessary) system features. If you reprogram the toolbars say, to remove the binocular icon, you may then need to program such facilities for your users.

Hope this helps

 

[gemma-the-husky]

Another thought

Somewhere in this thread you discussed ADO or DAO

I thought that depending on which reference is set first in the list, the object/function from the appropriate library will be used first. As some commands are duplicated but work differently, you may get a problem if you want an DAO function, but have ADO as the first named reference.

I hope my earlier post on hioding DBS window was appropriate as you seem to have made a lot of progresss anyway.

With regard to reports, I actually store all my report names in a table, and then generate a form from the table. I then give a print and preview command buttons and use the appropriate "application.runcommand openreport acpreview" or "application.runcommand openreport acnormal" (I think the syntax is about right. Using a table allows me to control which report each user sees, either by using Access login details, or directly from windows login info. I can also use this form to preset most report parameters from combo boxes etc, where required.

If you have hidden the DBS toolbars, the user can still right-click the preview report to get some of the print commands etc. He may lose the ability to save the report data as a spreadsheet, etc, dong it this way, but this is not a real problem generally anyway.

I hope this helps.