Projectnumb
  Home FAQ Contact Sign in
 
 Advanced search
MATCHING GROUPS



more...
POPULAR GROUPS

more...
found 172 articles for 0.305 sec
Hi Ray It often improves performance drastically if you turn off automatic calculation in the worksheet before performing a large amount of manipulation by automation. From memory, the property is EnableCalculation: objExcel.ActiveSheet.EnableCalculation = False It will also help to assign the sheet you are working with to a variable of type Excel.Worksheet: Set objXlSheet     

Group: microsoft.public.access.modulesdaovba · Group Profile · Search for Projectnumb in microsoft.public.access.modulesdaovba
Author: Graham Mandeno
Date: Aug 19, 2008 14:32

The goal is to iterate all the lines in an Excel worksheet and delete lines that have certain projects. Here is the code that I have in an MS Access function (the projects that need to be deleted are in a recordset): strSQL = "SELECT ProjectNumber FROM tblProjects WHERE TypeID=" & mTypeID Set rs = CurrentDb.OpenRecordset(strSQL) If Not rs.EOF Then rs.MoveLast
Show full article (2.85Kb) · Show article thread
All you guys are awesome! Thanks a bunch!!! Ray "Ken Sheridan" wrote: > Add a function along these lines to a standard module. You don't say what > first four digits distinguish between Partnership Type I and Partnership Type > II, so for this example I've assumed the former fall within the range 4000 to > 4999 and the latter are anything outside that range. You should be able to >     

Group: microsoft.public.access.modulesdaovba · Group Profile · Search for Projectnumb in microsoft.public.access.modulesdaovba
Author: Ray C
Date: Aug 19, 2008 08:15

Add a function along these lines to a standard module. You don't say what first four digits distinguish between Partnership Type I and Partnership Type II, so for this example I've assumed the former fall within the range 4000 to 4999 and the latter are anything outside that range. You should be able to amend the inner Select Case construct simply enough to cater for whatever the criterion
Show full article (1.57Kb) · Show article thread
First add a field to the manager table - MgrID - Autonumber - primary key. Add a new field to program table - MgrID - Number - Long Integer - foreign key. Set a one-to-many relationship from manager table MgrID to the MgrID of program table. Fill in or run an update query for the MgrID of the program table. Use these two queries unless you know subqueries and substitute your table and field     

Group: microsoft.public.access · Group Profile · Search for Projectnumb in microsoft.public.access
Author: Golfinray
Date: Aug 12, 2008 10:43

It's working now... I just re-did the queries from scratch and it worked. I must have had some extraneous piece of data in them before that was skewing the results. Thank you so much for all of your help!! "Klatuu" wrote: I'm still suspicious of query 1. I suggest you do some manual calculations by looking at the data in the tables. Then verify you are getting the correct numbers
Show full article (2.29Kb) · Show article thread
I'm still suspicious of query 1. I suggest you do some manual calculations by looking at the data in the tables. Then verify you are getting the correct numbers. I know you said it seems to be, but you need to be sure. Query 2 is so simple and straight forward, unless I am missing something, I don't see it being the problem. It also seems all you need to get what you are wanting from query     

Group: microsoft.public.access · Group Profile · Search for Projectnumb in microsoft.public.access
Author: Ken Sheridan
Date: Aug 12, 2008 09:46

Thank you for your help! Here are the tables that feed Query #1: FullName (*EmployeeID, FirstName, LastName, MI, Full) EmployeeRecord (*EmployeeID, DailyHours, Status, other misc. employee info) PeriodLookUp (*PeriodID, CycleEndDate, Period, PeriodDays) EmployeeCoS (*EmployeeID, *PeriodID, COS) Here's the Query #1 SQL: SELECT EmployeeRecord.EmployeeID, [Full Name].Full, EmployeeRecord
Show full article (2.12Kb) · Show article thread
You should not use an aliase ( [DEPR YEARS] ) within the same query that creates it as the query may try to use it before it is created. -- KARL DEWEY Build a little - Test a little "broncojim" wrote: > This could be the problem, but I'm not sure. The depr years are fields that > are created inside the selection queries. They do not exist in the main > tables. However, since this     

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: KARL DEWEY
Date: Jul 25, 2008 13:13

This could be the problem, but I'm not sure. The depr years are fields that are created inside the selection queries. They do not exist in the main tables. However, since this field is doing the same thing and has the same wording in each selection query, I simply copied and pasted the field from the first selection query to the others. Any ideas? "Golfinray" wrote: All of the
Show full article (2.58Kb) · Show article thread
    

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: HeatherD25
Date: Jul 22, 2008 20:47

Show full article (5.49Kb) · Show article thread
    

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: Klatuu
Date: Jul 22, 2008 13:21

Show full article (5.02Kb) · Show article thread
    

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: HeatherD25
Date: Jul 22, 2008 12:56

Show full article (4.26Kb) · Show article thread
    

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: KARL DEWEY
Date: Jul 18, 2008 14:11

Show full article (3.02Kb) · Show article thread
    

Group: microsoft.public.access.queries · Group Profile · Search for Projectnumb in microsoft.public.access.queries
Author: broncojim
Date: Jul 18, 2008 13:42

Show full article (2.71Kb) · Show article thread
1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · next