ErrorNumber 7753 (2002 (10.4302.4219) SP-2)

Topic

New Reply

I’m looking for a needle in a haystack. Has anyone ever encountered ErrorNumber 7753? We have a complicated Access database which utilizes VBA. We track errors in a log file. On 5/18/04 this error was generated four times by three separate people on three separate PCs running Access 2002 and Windows XP. What’s frustrating is that the ErrorDescription is simply a | (vertical bar)! We can’t find any reference to this error number in any Access documentation regarding error codes.

Any help would be appreciated! The database structure and VBA code is used nationwide but each facility has their own database/server. Our facility is the first one to encounter this. We’d like to solve this before anyone else encounters it.

Reply | Quote

Replies

Can’t find anything useful about this in the newsgroups. We would have to know what the circumstances are in which the error occurs.

Reply | Quote

I’ll try to provide some information but I don’t know how successful I’ll be. As a start, here’s ONE listing from the error log file (I’ve deleted identifying information for the actual PC and user):

CallingProcedure: frmCourseDates: SaveRecord
Computer Name:
UserName:
LoginName:
DateTime: 5/18/2004 9:20:09 AM
ErrorMessage: An unexpected error occurred that interrupted program execution.

Note: Checkpoint 2 Erl #15

ErrorDescription: |
ErrorNumber: 7753
ErrorSource: TEMPO

Form Name: frmCourseDates
Control Name: txtPatientSafetyHours
Control Value: 8

Operating System: Windows NT
Version: 5.1
Build: 2600
Processor Type: 586
System Directory: C:WINDOWSSystem32
Memory Status: 76%
Total Virtual: 2,147 MB RAM
Available Virtual: 1,894 MB RAM
Total Page File: 1,214 MB RAM
Available Page File: 1,006 MB RAM
Total Physical: 519 MB RAM
Available Physical: 121 MB RAM

All four of the 7753 errors have similar information. The Form Name is always frmCourseDates. The Control Name is always txtPatientSafetyHours. The Calling Procedure is either frmCourseDates: SaveRecord or frmCourseDates: UpdateCourseAttendeesList().

What makes this more unusual is that these same three people AND many more people used this same exact code the same day WITHOUT generating this error! The time of day that this occurred even varied from 8:00am until 1:40pm! If it was just one user who had this entry only once in the error log, we probably would just say that the system hiccupped.

Reply | Quote

I Googled and found this

Any use?

Reply | Quote

I found that one too, but it mentions error -7753 instead of 7753. The error log Loretta posted explicitly mentions 7753.

Reply | Quote

I found that one too, but it mentions error -7753 instead of 7753. The error log Loretta posted explicitly mentions 7753.

Reply | Quote

Thanks Steve for the lead. We’re guessing that it was a LAN issue that day.

Reply | Quote

To determine if the post Steve found is on target, does your application use ODBC to link to SQL Server or another database server (i.e. Oracle, DB2, Informix, etc.). If so, that’s a good bet, and the LAN being the culprit is also very plausible.

Reply | Quote

We are definitely using ODBC to connect to the backend of the database but it’s an Access database. That’s why we’re guessing that our LAN was the culprit. (We wish we could use SQL Server but there are silly politics involved with that.) We’re considering installing Office XP SP-3 and the newest Jet 4.0 SP8 (see KB829558). I don’t remember if the National VA IT folks have authorized us to install these yet. (The fun of working in a LARGE beaucracy. )

We TRULY appreciate Steve pointing us in the direction of probable problem so we can hopefully prevent this from happening again!

Reply | Quote

If you are using ODBC to connect an Access front-end to an Access back-end, that is highly unusual. The far more common approach to that is to simply link to the tables, which does not use an ODBC driver, and shouldn’t give errors of the kind you saw. In point of fact I’ve only used the ODBC driver for Access a few times to attach Access data to a SQL Server project – so I can’t attest to the robustness of it. Unfortunately, Access does tend to be very sensitive to network issues, which is one of the reasons for projects with more than a few users we move the back-end to SQL Server. Doing so isn’t a panacea, as it solves a number of problems, but also creates some new issues you have to be aware of. And to get the best performance you need to redo some of the data sources to take advantage of the SQL Server database engine. Good luck with convincing them to make your system more robust. If we can provide amunition for you, don’t hesitate to post.

Reply | Quote

But the attached tables are ODBC linked, even if it isn’t obvious. It’s just that you create the links differently. In earlier versions of Access, it wouldn’t let you select an Access mdb as an ODBC database connection and I’ve never tried it in 2002.

Reply | Quote

Access 2002 still doesn’t let you import or link a table in another Access database through ODBC.

Reply | Quote

Access 2002 still doesn’t let you import or link a table in another Access database through ODBC.

Reply | Quote

But the attached tables are ODBC linked, even if it isn’t obvious. It’s just that you create the links differently. In earlier versions of Access, it wouldn’t let you select an Access mdb as an ODBC database connection and I’ve never tried it in 2002.

Reply | Quote

If you are using ODBC to connect an Access front-end to an Access back-end, that is highly unusual. The far more common approach to that is to simply link to the tables, which does not use an ODBC driver, and shouldn’t give errors of the kind you saw. In point of fact I’ve only used the ODBC driver for Access a few times to attach Access data to a SQL Server project – so I can’t attest to the robustness of it. Unfortunately, Access does tend to be very sensitive to network issues, which is one of the reasons for projects with more than a few users we move the back-end to SQL Server. Doing so isn’t a panacea, as it solves a number of problems, but also creates some new issues you have to be aware of. And to get the best performance you need to redo some of the data sources to take advantage of the SQL Server database engine. Good luck with convincing them to make your system more robust. If we can provide amunition for you, don’t hesitate to post.

Reply | Quote

We are definitely using ODBC to connect to the backend of the database but it’s an Access database. That’s why we’re guessing that our LAN was the culprit. (We wish we could use SQL Server but there are silly politics involved with that.) We’re considering installing Office XP SP-3 and the newest Jet 4.0 SP8 (see KB829558). I don’t remember if the National VA IT folks have authorized us to install these yet. (The fun of working in a LARGE beaucracy. )

We TRULY appreciate Steve pointing us in the direction of probable problem so we can hopefully prevent this from happening again!

Reply | Quote

To determine if the post Steve found is on target, does your application use ODBC to link to SQL Server or another database server (i.e. Oracle, DB2, Informix, etc.). If so, that’s a good bet, and the LAN being the culprit is also very plausible.

Reply | Quote

Thanks Steve for the lead. We’re guessing that it was a LAN issue that day.

Reply | Quote

I Googled and found this

Any use?

Reply | Quote

Take a very good look at the SaveRecord and UpdateCourseAttendeesList procedures, and see if and how they refer to txtPatientSafetyHours. Hopefully, you’ll get an idea what could go wrong. You can also make a copy of the database and perform stress testing – open the frmCourseDates form, and repeatedly enter or modify data in txtPatientSafetyHours (and other controls) to see if you can reproduce the error.

Reply | Quote

Take a very good look at the SaveRecord and UpdateCourseAttendeesList procedures, and see if and how they refer to txtPatientSafetyHours. Hopefully, you’ll get an idea what could go wrong. You can also make a copy of the database and perform stress testing – open the frmCourseDates form, and repeatedly enter or modify data in txtPatientSafetyHours (and other controls) to see if you can reproduce the error.

Reply | Quote

I’ll try to provide some information but I don’t know how successful I’ll be. As a start, here’s ONE listing from the error log file (I’ve deleted identifying information for the actual PC and user):

CallingProcedure: frmCourseDates: SaveRecord
Computer Name:
UserName:
LoginName:
DateTime: 5/18/2004 9:20:09 AM
ErrorMessage: An unexpected error occurred that interrupted program execution.

Note: Checkpoint 2 Erl #15

ErrorDescription: |
ErrorNumber: 7753
ErrorSource: TEMPO

Form Name: frmCourseDates
Control Name: txtPatientSafetyHours
Control Value: 8

Operating System: Windows NT
Version: 5.1
Build: 2600
Processor Type: 586
System Directory: C:WINDOWSSystem32
Memory Status: 76%
Total Virtual: 2,147 MB RAM
Available Virtual: 1,894 MB RAM
Total Page File: 1,214 MB RAM
Available Page File: 1,006 MB RAM
Total Physical: 519 MB RAM
Available Physical: 121 MB RAM

All four of the 7753 errors have similar information. The Form Name is always frmCourseDates. The Control Name is always txtPatientSafetyHours. The Calling Procedure is either frmCourseDates: SaveRecord or frmCourseDates: UpdateCourseAttendeesList().

What makes this more unusual is that these same three people AND many more people used this same exact code the same day WITHOUT generating this error! The time of day that this occurred even varied from 8:00am until 1:40pm! If it was just one user who had this entry only once in the error log, we probably would just say that the system hiccupped.

Reply | Quote

Can’t find anything useful about this in the newsgroups. We would have to know what the circumstances are in which the error occurs.

Reply | Quote