• WSDrew

    WSDrew

    @wsdrew

    Viewing 15 replies - 766 through 780 (of 790 total)
    Author
    Replies
    • in reply to: Logging Off Automatically #637970

      I don’t think there is a normal setting to force a logoff after a specific idle time. This sounds like it is a screen saver response. You can have a screen saver lock your desktop, but you could also get screen savers (or build one) that either automatically have the ‘logoff’ option, or you can get some that let you ‘run’ an .exe or batch file. It is very easy to force a logoff through a batch or .exe.

      I would be sniffing around the screen saver settings, to see if it’s the culprit.

      Drew

    • in reply to: Email from Access? (A2k (9.0.3821) SR-1) #637967

      Just another vote for ASPEmail. I use it myself. There is a ‘pro’ version which costs money, but the free version is very acceptable with it’s abilities.

      Of course, if you are really adventurous, you can make your own smtp client. I have a VB sample if you want. (Needed a method of ‘resending’ filtered emails. Emails filtered by our Spam filter go to the user with a ‘default blocked’ message. Sometimes there is a falsely blocked email.)

      Drew

    • in reply to: Security question (Access 97 win2k) #637966

      All of the security information that I have come across say one thing for certian, that you must remove permissions from the Admin user and Admins group. The reasoning is, the User to Group relationships are stored in the .mdw file, so if the Admins group still has permissions, so will the Admin user, when a default .mdw is used.

      I personally disagree with the removing all approach in some cases. I have had many databases that needed to have ‘general’ access, and Admin access. In those cases, I strip the permissions from the Admins group, and leave the permissions I want in the Admin user. I then have an ‘admin’ .mdw, which has accounts with full access. I then only have to put the ‘admin’ workgroup on the admin user machines (or on the network, but there are cheap hack utilities out there), and setup a shortcut to run the database with that .mdw. That way I don’t have to go around to everyone’s machine.

      Drew

    • in reply to: Opening forms in Dialogue mode (Access 97 Win2k) #637964

      Just to throw my two cents in:

      It’s been explained about modal forms already in this thread. However, just to bring in another aspect, all code works this way, whether it is on a form or not. When a function or sub, calls another function or sub, the calling function/sub pauses until the new function or sub hits and End Function/Sub, or Exit Function/sub. That is part of ‘single threading’. Your application runs in one thread, so your code follows a simple step by step procedure. Now, you can have multiple forms running seperate functions, but in reality, your code is only doing one line at a time, in fact it does one function/sub at a time, unless you use DoEvents, which frees the thread up to run code that is waiting.

      Access forms are Class modules. If you have ever made your own class modules, you’d know that a Class module has an Initialize event. If you put a loop in that event, the calling function/sub waits until the class is completely initialized. You could create a ‘modal’ class, by putting:

      Do while boolStopLoop=False
      DoEvents
      Loop

      Have the boolStopLoop variable as a global, or Class based variable. If that is in your Initialize code, you class will work, and keep it’s calling code ‘paused’. When you close your class (there is a terminate event), you simply set the boolean variable to True, stopping the loop, and allowing your calling code to continue.

      I personally have never done this, so I could be wrong on whether it works or not. What’s more important is the concept of how your code works.

      Drew

    • in reply to: Problem returning Date from Control? (A2k (9.0.3821) SR-1) #637963

      Just a thought, I think this thread is solved, but there a ton of form based popup calendars out there. (I have one on my site.). This doesn’t seem like a very tricky issue, but having a form based calendar has several advantages. The biggest is that you are not using an ActiveX control that must be setup on the client machines. The second, you have code that you can modify, to custom fit the application.

      Drew

    • in reply to: Formatting text output (97) #637014

      No, I don’t think so. I was thinking more along the lines of doing that in VB 6.0, creating an ActiveX control, and using that within Access. ( Because you never know when you would want to interact with that data from something else, like VB, ASP, etc, and if they are in a .dll, you just reference it.)

      Drew

    • in reply to: Disappearing Programs #637011

      Ack, I’d take Access over Excel any day!

      You could get adventurous and write a small little VB program to edit the data. (Wouldn’t even have to have an interface, just set the coordinates to something within an 800 by 600 range.)

      Drew

    • in reply to: Formatting text output (97) #636961

      Sounds like a perfect spot to use Implements, if I have ever heard one.

      Implements lets you create one interface, which can use multiple classes.

      You could build a blank class (read MSDN articles about Implements) that would replicate functions similar to ADO (RecordCount, EOF, BOF, MoveFirst, etc.), then build individual classes for each type of format. That way, you can use the Implements class in all of your code to interact with the data, and to allow the class to interact correctly, you simply tell it which type of implements to use.

      Drew

    • in reply to: Disappearing Programs #636952

      Nope, I don’t have anything like that installed. You should be able to connect to the 95 mdb using any version of Access (95 or later), by creating a blank ‘new version’ database, then create linked tables to the 95 .mdb.

      Drew

    • in reply to: How many users max out Access 2000? (2000) #636951

      Unbound solutions are not for the faint of heart! The bound capabilities of Access forms/reports are a very powerful and useful feature of Access. Using an unbound approach can be a bit more work, but you are dealing with a clean slate, and empty framework, you don’t have to build backwards. Unbound solutions can be faster then bound solutions. You are doing the same thing, with code, as the bound process is doing internally. The reason it can be faster, is that you can skip some processes that you may not want/use.

      The best way to approach an unbound solution is to build Class modules to store your stuff in collections, so you read and write data only when necessary, and you fill your form objects with the classes and collections.

      Drew

    • in reply to: Logon script question… #636802

      Go to a command prompt, and type runas. It will show you the command line arguments to run a program as another user. Just a suggestion, but I would make a new ‘temporary’ account, set that up as a Domain Admin, and use that account to do this job. Then delete the account. You can hide the batchfile process (echo off), but it’s better safe then sorry.

      Drew

    • in reply to: Web Enabled Access DB (Access 2000) #636800

      The VBA tutorial I posted about earlier would be a handy thing to go through to help you learn VB. One, it teaches using Access 97, so it’s an environment you should already be familiar with. It will just show you another side to that environment. It’s about 50 or 60 pages, and though it doesn’t go into the really advanced stuff, it should give you a solid foundation to begin expiramenting on your own (that’s when you learn the most). Once you have VBA under your belt, VB is not a very big jump. Now instead of trying to tackle everything all at once, you’ll have the language down, and you’ll just have to deal with a new GUI.

      I have found that the people I know that learned VBA in Access, and then picked up VB, learned to appreciate both equally. And they also seem to feel, like I do, that Access is an easier method of learning the language, since Access doesn’t throw a ton of concepts at you, all at once. I have also found those that learn VB in VB (like VB 6.0), tend to shy away from programming in Access, because they feel it’s limited. The fact is they are both well suited for the tasks they are designed for.

      Anyhow, not to toot my own horn…, but I have gotten a lot of positive feedback on that tutorial. So if you do decide to read it, let me know if you have any comments or suggestions. I actually wrote it a few years ago, when I had some Access Dev’s here at my job that had no VBA experience, but were using the heck out of Access. Eventually I started handing it out to people on the various groups I watch, and then finally decided to post it on my site. (If you do read it, forgive the grammar, I reread it like 2 months ago, and I was wondering if English was really my primary (and only language). hehehe Just have been too busy to correct it all. Currently I am working on another tutorial, a bit more advanced, about Classes and Collections. When I get that done, I’ll go back and edit the VBA tutorial.

      Drew

    • in reply to: How many users max out Access 2000? (2000) #636799

      First suggestion. Revert your backend back to Access 97. A2k has a 2 gig limit, opposed to 97’s 1 gig limit, but A2k and up uses Unicode, instead of ASCII, which takes up twice the space. Thus twice the work to read off of a drive, and probably twice the network bandwidth (not sure on the bandwidth issue).

      Next, development wise, there are two camps. Go unbound, so your framework is as light as possible. I use what I like to call a ‘hit and run’ method. Hit the backend to read/write data then disconnect. I have db’s that used to handle 180+ users. (Downsizing has taken us down to 60+ users). With ‘hit and run’, even with 180 users, you are rarely getting more then a handful at the same time.

      The other camp is bound, which is a valid approach, and probably what you have in place. There are several techniques which can seriously improve bound performance. To begin with, whenever data entry is occurring, use forms with Data Entry turned to Yes. This prevents the users from seeing previous records, but it also serious improves performance, since you are only adding, not reading/writing. You can also lighten the connection load in bound front ends, it just takes time to go through each process to determine where users are ‘hogging’ the database.

      Drew

    • in reply to: Web Enabled Access DB (Access 2000) #635939

      Hmmm, not to contradict your friend, but if you have Access Experience, just no programming experience, wouldn’t it be easier to learn a bit of programming with VBA, instead of a language that is foriegn to Access?

      I use Access and VB interchangably, but when I first saw the VB Environment, it took a little bit to get my feet planted. What helped immensely was my VB skills inherent in learning VBA in Access. I already understood the flow and some of the tricks. Going into VB was much easier that way.

      I haven’t seen C# yet, so I can’t comment on it’s learning curve, but I would be willing to be a beer that it’s interface is going to be quite a bit different from Access.

      Drew (Good luck….)

    • in reply to: Web Enabled Access DB (Access 2000) #635858

      (Edited by charlotte on 02-Dec-02 18:43. to activate link)

      I have a tutorial for VBA, and an Intro to ASP tutorial on my site. http://www.wolfwares.com[/url%5D (I must say the VBA is far more complete then the ASP though, ASP is pretty simple once you have a good foot hold in VB/VBA, since it is VB Script, with 5 extra objects.)

      Drew

    Viewing 15 replies - 766 through 780 (of 790 total)