Closing Form

sohailcdc

Registered User.
Local time
Today, 08:18
Joined
Sep 25, 2012
Messages
55
Hello there
I am just trying to learn during my free time and need help from Access Guru
I am trying to learn the controls therefore, my table consist of only 3 field
customer ID, Name, Relationship (all fields are text)

form is unbound

I put two checks at customer ID
1) duplicate id - working perfectly, with the help of forum thanks to JHB
2) customer id can't be nil - work perfectly with the help of forum

Here's my is problem, when I try to close the form using close button (both code given below) - i received the message Customer ID can't be NIL, therefore, every time i put any value in the field to close the form

here's the Customer ID Can't be NIL code

Private Sub Txtcid_Exit(Cancel As Integer)
On Error GoTo txtcid_exit_err
If Len(Me.Txtcid.Text) = 0 Then
MsgBox "Customer ID can't be NIL", , "Information"
Cancel = True
End If
txtcid_exit_exit:
Exit Sub
txtcid_exit_err:
Resume txtcid_exit_exit
End Sub

here's the closing form button code

Private Sub Butclose_Click()
DoCmd.Close
End Sub
 
try going back to your table and setting customerid to autonumber - it will then populate automatically
 
Thanks CJ_London
Autonumber is numeric field, I am just trying to learn
e.g. user have its own access to create its own ID, could be numeric or could be alpha numeric
 
Hello sohailcdc, I read through your description.. I have a few concerns..You mentioned..
...(all fields are text)
Why is ID Text? It would be more easier for you in future to make it a Number as CJ_London has advice change it to AutoNumber..
form is unbound
Again Why is this? The main idea of having access is to have bound forms so that manipulation of data in table would be more easier, with lesser coding.. Unless this is a Search Form or New data entry ID checking form..
Here's my is problem, when I try to close the form using close button (both code given below) - i received the message Customer ID can't be NIL, therefore, every time i put any value in the field to close the form
If the form is unbound why is there a need to check for Length of the Customer ID? These questions come up basically because I do not know your DB setup.. but are some questions that you might need to address..
 
thanks pr2-eugin

There's nothing specific reason, I am just trying to learns control using unbound form
What I do during my free time try different scenarios and play with the code (nothing else)

like field formats, duplicate record, popup messages, change field colour upon specific colour, check box, etc etc
 
...I am just trying to learns control using unbound form...

I cannot think of a worse way to learn about Access than using Unbound Forms! Using Unbound Forms does away with the main reason that developers choose to use Access, which is to take advantage of it ability to facilitate the RAD (Rapid Application Development) of Databases.

With Bound Forms, Access does the vast majority of the heavy lifting; with Unbound Forms the developer has to write code for just about everything, even the most mundane tasks. Several developers I know, experienced in Visual Basic database development, as well as Access development, estimate that development, using Unbound Forms, by highly experienced developers, takes two to three times as long, using Unbound Forms, as it does when using Access and Bound Forms.

In short, there is very little that can be done using Unbound Forms that cannot be accomplished with Bound Forms, and usually done with less work!

Anyone who insists on using Unbound Forms, would be far better off using a straight VB or C++ front end with a SQL Server or Oracle back end.

  • You can create an EXE file which gives total protection to your code/design
  • You can distribute the db to PCs without a copy of Access being on board
  • Your data security is far, far better than anything you can do in Access

It should be added that there are a few very specialized reasons for using Unbound Forms in Access, for general data entry of Records, but they are very specialized, and situations that a newbie is very unlikely to come upon. I've been writing Access apps for well over a decade now, and have never had the need for using Unbound Forms for general data entry.

I applaud you efforts to learn Access, but you should first learn to use it as it is intended to be used, then you can move on to modifying its behavior, if the occasion arises.

Linq ;0)>
 
I cannot think of a worse way to learn about Access than using Unbound Forms! Using Unbound Forms does away with the main reason that developers choose to use Access, which is to take advantage of it ability to facilitate the RAD (Rapid Application Development) of Databases.

With Bound Forms, Access does the vast majority of the heavy lifting; with Unbound Forms the developer has to write code for just about everything, even the most mundane tasks. Several developers I know, experienced in Visual Basic database development, as well as Access development, estimate that development, using Unbound Forms, by highly experienced developers, takes two to three times as long, using Unbound Forms, as it does when using Access and Bound Forms.

In short, there is very little that can be done using Unbound Forms that cannot be accomplished with Bound Forms, and usually done with less work!

Anyone who insists on using Unbound Forms, would be far better off using a straight VB or C++ front end with a SQL Server or Oracle back end.

  • You can create an EXE file which gives total protection to your code/design
  • You can distribute the db to PCs without a copy of Access being on board
  • Your data security is far, far better than anything you can do in Access
It should be added that there are a few very specialized reasons for using Unbound Forms in Access, for general data entry of Records, but they are very specialized, and situations that a newbie is very unlikely to come upon. I've been writing Access apps for well over a decade now, and have never had the need for using Unbound Forms for general data entry.

I applaud you efforts to learn Access, but you should first learn to use it as it is intended to be used, then you can move on to modifying its behavior, if the occasion arises.

Linq ;0)>
^^^^^^^^^^^ + 1 ^^^^^^^^^^^^^^^^^^^^^^^^^
What he said
 

Users who are viewing this thread

Back
Top Bottom