Databinding lost synchronizations (possible a Bug)

[Guest]

Hi,

Harjit an Employee of MSFT sayed I should ask the Question in this forum,
the orginal Post is:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2275398&SiteID=1.

My problem is follow:

Our company developing an Access Solution, we work the most time with
Access. Our Customers use our product the most time of there daily work and
the Mount of Data is rising up very quickly. The important working table has
more than 128000 Rows (like Customers or Products).



For editing we use a Form and bind it to a Query. The Amount of the Rows is
more than 1300000 rows.

If the Count of Rows in a Form is greater than around 128000 rows,
forms.Recordset.findfirst find a Row (check with recordset.noMatch) but the
Form doesn't noticed that the Data in the Recordset is changed and showed the
content of another Row. The Cursor Position is at 13000, not at 128xxx.

In some cases the Data (row >128000) is display valid, but after changing
the Datarow, another (with a lower Position) will be override.


CODE

Me.Recordset.FindFirst BuildCriteria("id", dbLong, p_id)
If Me.Recordset.NoMatch Then
MsgBox "Der Record couldn't found!" vbOKOnly + vbQuestion,
"Adressen-Suche"
exit sub
else
if p_id <> Me.Id Then 'Check Form sync. doesn't work
MsgBox "Serach Error!"
end if
end if


I hope I describe the Problem fully understandable.
If there any Questions, you can contact me.

Greats from winterly Austria
Andreas

 

[Guest]

I have not had to deal with tables of the size you have with the Jet database
engine. I have delt with 1meg tables in Sybase. Have you considered
switching to SQL Server? A stored procedure can do what you want very neatly.
How long does it take to load 100k+ records? Maybe you should try an unbound
form with a query in the onLoad event that selects a desired subset of the
records. Or the form header could have controls to collect the selection
criteria and a command button to run a parameterized query and set the form
recordset.

 

[Guest]

Hi,

Our solution is fully use Access. We tried to move to SQL, but there is not
so fast as an whole Access solution. If I link the table to an SQL it was the
same Problem. The Loading is very Quick <3 Sec.

In the form we have a Search Button, (the Code I describe above), it find
the right entry. Its not an time Problem. It think this is an little bug in
the Access Form. I think a lot about the Problem and post it in the MSDN
forum (link is in the first post).

Thanks for your fast replay
Andreas