Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / January 2008

Tip: Looking for answers? Try searching our database.

Visual Basic Not Waiting for Query to fully evaluate???

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Vince - 28 Dec 2007 21:19 GMT
Hello all,

I am using Visual Basic to open a saved query and then save
information in the query to an array for later use.  The problem is
that the same query shows different results when opened directly vs.
when opened by Visual Basic.  It is as if Visual Basic is not letting
the query fully evaluate before processing records.

The query is a subtotal query that contains several criteria set up as
"where" in the group-by box.  Most of the criteria are based on one
table, one criteria is based on a second joined table.  When the query
is opened directly this last criteria is correctly evaluated and the
proper records are shown.  When opened in VB it is as if this criteria
did not exist.  The query otherwise shows correct information except
it includes records that should not be there based on the last
criteria.

Is there a way to force visual basic to wait until a query is fully
opened before executing code that uses the resulting records.  Or is
there something else that I am missing.

Any help would be greatly appreciated.

Thanks,

Vince

Partial code Follows---------------------------------
Public aWork(10) as Integar

Sub LoadWorkArray(WorkQuery as string)  'WorkQuery = query name
Dim WorkLastRecord as Integar
Dim X as Integar

Set SLWork = New ADODB.Recordset

SLWork.Open WorkQuery, CurrentProject.Connection, adOpenKeyset,
adLockOptimistic

WorkLastRecord = SLWork.RecordCount

ReDim aWork(WorkLastRecord + 1)

With SLWork
   .MoveFirst
   For X = 1 To WorkLastRecord
       aWork(X) = ![Attending Number]
      .MoveNext
   Next X
   .Close
End With

End sub
lyle - 28 Dec 2007 21:41 GMT
> Hello all,
>
[quoted text clipped - 49 lines]
>
> End sub

I use ADODB a lot but I can't guess why you are getting more records
than yu think you should. Are you using wild cards such as "*";
generally ADODB will epxect "%".

Is this a DAO saved query?
If so have you Declared it as such, Initialized it and Debug.Print
(ed) its SQL. Is the SQL what you think it should be?

My method of getting an array of records (one field):

Dim Array0fSchools$()
Array0fSchools = Split(CurrentProject.Connection.Execute("SELECT
[Name] FROM Schools ORDER BY Name").GetString(adClipString, , "",
vbNewLine, ""), vbNewLine)

The last line is all one line.
If the SQL is complicated I build it and assing it to a string
variable.
lyle - 28 Dec 2007 21:47 GMT
> > Hello all,
>
[quoted text clipped - 68 lines]
> If the SQL is complicated I build it and assing it to a string
> variable.

I neglected to mention that this gives one extra empty element at the
end of the array, which can be dealt with any number of ways.
Mark - 28 Dec 2007 23:14 GMT
I'm no expert but would it not be worth adding a line before you go to the
beginning of the recordset to go to the end of the recordset. I think this
would force the query to be fully executed before evaluating the values
returned from it.

Something like:

With SLWork
   .MoveLast
   .MoveFirst
   For X = 1 To WorkLastRecord
       aWork(X) = ![Attending Number]
      .MoveNext
   Next X
   .Close
End With

Regards,

Mark

> Hello all,
>
[quoted text clipped - 49 lines]
>
> End sub
Vince - 28 Dec 2007 23:36 GMT
> I'm no expert but would it not be worth adding a line before you go to the
> beginning of the recordset to go to the end of the recordset. I think this
[quoted text clipped - 72 lines]
>
> - Show quoted text -

Hello Lyle,

You got it with using an "*" vs "%".  The query was using a Not Like
"*string*" expression.  Changed it to use % instead and now it works.
You do not know how long I have been looking at everything but the
string.  While the query opens normally from Access the ADODB
apparently totally ignores an expression that uses an *.

Thanks for everybody's help.

Vince
David W. Fenton - 29 Dec 2007 01:23 GMT
> You got it with using an "*" vs "%".  The query was using a Not
> Like "*string*" expression.  Changed it to use % instead and now
> it works. You do not know how long I have been looking at
> everything but the string.  While the query opens normally from
> Access the ADODB apparently totally ignores an expression that
> uses an *.

Why are you using ADO? Makes no sense to me.

Signature

David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Vince - 01 Jan 2008 21:30 GMT
> > You got it with using an "*" vs "%".  The query was using a Not
> > Like "*string*" expression.  Changed it to use % instead and now
[quoted text clipped - 8 lines]
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/

Hi David,

It was a way of opening a query inside VB to populate an array.  I
also tried opening the query as the DAO recordset type of object and
got the same results.  I had done this in a number of other queries
but this is the first one I had a problem with.  I would be open to a
better approach.

Thanks,

Vince
Vince - 01 Jan 2008 21:36 GMT
> On Dec 28 2007, 8:23 pm, "David W. Fenton"
>
[quoted text clipped - 26 lines]
>
> - Show quoted text -

Excuse me,  I meant to say I had tried opening the recordset as its
default object type and got the same results.
David W. Fenton - 01 Jan 2008 22:19 GMT
Vince <VArgenziano@yahoo.com> wrote in
news:58d9285f-2ae9-4bae-b05f-9fa959c8e101@e50g2000hsh.googlegroups.co
m:

> Excuse me,  I meant to say I had tried opening the recordset as
> its default object type and got the same results.

The default object type depends on what references your database
has. Which references you get by default depends on which version of
Access you created the MDB with.

Signature

David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

Vince - 03 Jan 2008 20:45 GMT
On Jan 1, 5:19 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
> Vince <VArgenzi...@yahoo.com> wrote innews:58d9285f-2ae9-4bae-b05f-9fa959c8e101@e50g2000hsh.googlegroups.co
> m:
[quoted text clipped - 9 lines]
> David W. Fenton                  http://www.dfenton.com/
> usenet at dfenton dot com    http://www.dfenton.com/DFA/

I did check references and it does list DAO before Activex data
objects.  This is the MS office original order and prior to this have
not really given it much thought. For my part the only time I use
recordset objects in VB is to open saved queries as described above so
it has not been an issue but I will be looking at it more due to the
problem that I had with my query's wildcard expression.

Thanks,

Vince
David W. Fenton - 03 Jan 2008 21:18 GMT
> On Jan 1, 5:19 pm, "David W. Fenton"
> <XXXuse...@dfenton.com.invalid> wrote:
[quoted text clipped - 16 lines]
> above so it has not been an issue but I will be looking at it more
> due to the problem that I had with my query's wildcard expression.

I never ever use ADO, but, in fact, I preface all my variable
declarations with library:

 Dim db As DAO.Database
 Dim rs As DAO.Recordset

The first is not even necessary, as the Database data type is
specific to DAO, but it just makes the code clear and easy to use,
and I'm guaranteed it will never break as long as there's a DAO
reference.

Signature

David W. Fenton                  http://www.dfenton.com/
usenet at dfenton dot com    http://www.dfenton.com/DFA/

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.