SA,
How do I prevent previously submitted form data from being reinserted into the database when the user presses the browser’s Refresh button?

- there are a little solutions but i think the next one is the best :
solution : you need to determine that the user has refreshed the page in the browser instead of pressing the form’s submit button.
A simple way to implement refresh trapping is by the use of a date/time stamp held in a ViewState variable and a date/time stamp held in the user’s Session. On the page’s PreRender event, a ViewState variable is set to the value of the Session variable. These two values are compared to each other immediately before the database INSERT command is run.
If they are equal, then the command is permitted to execute and the Session variable is updated with the current date/time, otherwise the command is bypassed.
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
Session["Update"] = Server.UrlEncode(System.DateTime.Now.ToString());
}
}

protected void Page_PreRender(object sender, EventArgs e)
{
ViewState["Update"] = Session["Update"];
}

protected void Button1_Click(object sender, EventArgs e)
{
if (Session["Update"].ToString() == ViewState["Update"].ToString())
{
// Your Code
Session["Update"] = Server.UrlEncode(System.DateTime.Now.ToString());
}
else
{
// Error
}
}

i found nice web tool to convert VB.NET to C# and vice versa  …

http://www.developerfusion.com/tools/convert/vb-to-csharp/ ,

maybe be useful

Language Differences

Understanding the differences between VBA and Visual Basic .NET can help you make a more informed decision about converting your code. This section examines differences in the following areas:

• Language
• Project management
• Security
• Deployment

Because Visual Basic .NET was designed to take advantage of the .NET Framework, it contains many changes and areas where compatibility with previous versions of the language has not been preserved. The following is a partial list of changes to the Visual Basic language in Visual Basic .NET. For more information, see Introduction to Visual Basic .NET for Visual Basic Veterans.

Late Binding. VBA and Visual Basic .NET support late binding; however, using early-bound objects makes your code easier to read and maintain and enables IntelliSense. Visual Basic .NET introduces the Option Strict On statement, which enforces early binding and prevents implicit conversion where data might be lost. The compiler default is Option Strict Off. One reason this is important is that many of the methods and properties of Office objects return the type Object, and you must explicitly convert the object to the correct type, as shown in the following example:

' Using Ctype to convert the Object.returned by Sheet1 to a Worksheet.
MsgBox(CType(ThisWorkbook.Worksheets("Sheet1"), Excel.Worksheet).Name)

Declaring Variables.   In VBA, you can use the Option Explicit statement to enforce explicit variable declaration. You can also set this automatically by selecting the Require Variable Declaration check box in the VBA IDE options, which by default is not selected. All implicitly declared variables are of Variant type.

The Visual Basic .NET compiler enforces explicit declaration, requiring that every variable be declared. You can override this by using the statement Option Explicit Off. All implicitly declared variables are of Object type. You should consider this when copying and pasting code from VBA to Visual Basic .NET, because the Variant data type is no longer supported and will automatically be converted to the Object data type. You should explicitly type all variables declared in your project.

Default Properties.   In Visual Basic .NET, default properties are only supported if the properties take arguments. In VBA, you can use shortcuts when typing code by eliminating the default properties. For example:

ActiveDocument.Tables(1).Cell(1, 1).Range = "Name"

When converting this code to Visual Basic .NET, you must type out the default property of the Range object, which is Text:

ThisApplication.ActiveDocument.Tables(1).Cell(1, 1).Range.Text = "Name"

Note that the default property for the Tables object, Item, is not required because it takes an index parameter. However, your code will be more readable if you include all of the default properties:

ThisApplication.ActiveDocment.Tables.Item(1).Cell(1, 1).Range.Text _
    = "Name"

ByVal, ByRef Parameters. In VBA, parameters are passed by reference by default. In Visual Basic .NET, parameters are passed by value by default. When preparing your code for conversion to Visual Basic .NET, you might want to check that all methods explicitly define whether the parameters should be passed by reference or by value. When you paste code into the Visual Studio .NET IDE with parameters that are not defined,ByVal is automatically added to each parameter in the list.

Enumerations. Enumeration constants must be fully qualified in Visual Basic. NET. When converting your VBA code, you must add the fully qualified enumeration name to both Word and Excel constants. For example, when performing a search in Word VBA, you specify the FindWrapvalue of the Selection or Range using a wd constant. Three options are given: wdFindStop, wdFindAsk, and wdFindContinue. In VBA, you can simply assign the constant because the enumeration is global to your project:

Selection.Find.Wrap = wdFindContinue

In Visual Basic .NET, you must fully qualify the constant with the enumeration name:

ThisApplication.Selection.Find.Wrap = Word.WdFindWrap.wdFindContinue

This may seem like a lot of extra typing, but if you use the IntelliSense feature of Visual Studio .NET, locating and typing the qualified constants is relatively easy, and it makes your code more readable. If you are already familiar with the constant names, you will find that the enumeration name often closely matches the constant name. In the case above, they both contain wdFind. To explore the available enumerations, type Word.Wd and scroll through the items available in the IntelliSense drop-down list (type Excel.XL to scroll through the list of available enumerations for Excel).

Non-Zero Bound Arrays. In VBA, the default lower bound of an array dimension is 0 (zero). Using Option Base, you can change this to 1. In Visual Basic .NET, the Option Base statement is not supported, and the lower bound of every array dimension must be 0. Additionally, you cannot use ReDim as an array declaration. One thing to keep in mind when working with Office collections from Visual Basic .NET is that the lower array bounds of most Office collections begin with 1.

Use of Parentheses with Method Calls. In VBA, parentheses are optional in some cases when you call subroutines, and it is sometimes difficult to remember when they are required. In Visual Basic .NET, parentheses are required when passing parameters in a method call.

Set Keyword. In VBA, the Set keyword is necessary to distinguish between assignment of an object and assignment of the default property of the object. Since default properties are not supported in Visual Basic .NET, the Set keyword is not needed and is no longer supported. This change is illustrated in the following examples:

' VBA
Dim mySelection as Selection
Dim myOtherSelection as String
Set mySelection = Selection
myOtherSelection = Selection

' Visual Basic .NET
Dim mySelection As Word.Selection
Dim myOtherSelection As String
mySelection = ThisApplication.Selection
myOtherSelection = ThisApplication.Selection.Text

Data Access. Data binding to a Data Access Object (DAO) or Remote Data Object (RDO) data source is not supported in Microsoft Visual Basic .NET. ActiveX® Data Objects (ADO) data binding is supported for backward compatibility; however, you may want to consider converting to ADO.NET. For more information, see Comparison of ADO.NET and ADO.

Conversion of UserForms to Windows Forms. VBA UserForms cannot be copied or imported into Visual Studio .NET. In most cases, you will need to recreate your forms as Windows Forms. The use of drag-and-drop controls is consistent with creating forms in VBA, but event handlers for Windows Form controls are handled differently. Many new features are available to make creating your forms easier than before, for example:

• Control anchoring is now possible, so that when a user resizes your form, the controls automatically resize and reposition properly.
• Setting tab order is much easier with Windows Forms. Enable tab ordering by clicking Tab Order on the View menu. Then simply click each control in the preferred order.
• Creating menus in-line is an improvement over menu creation in VBA.
• In VBA, you can show a form as vbModal or vbModeless. In Visual Basic .NET, the ShowDialog method is used to display a form modally; the Show method is used to display a form non-modally. Note, however, that the form will display non-modally, but when you click in the Word or Excel document, the form moves to the background, which can be confusing to your users.
• Many new form controls are also available in Visual Basic .NET, such as data-entry validators, common dialog boxes, hyperlinked labels, system tray icons, panels, numeric-up/downs, on-the-fly designable tree views, Help file linkers, ToolTip extenders, and more

Project Management Differences

When you start using Visual Basic .NET to create your Office solutions, one difference you will notice is the location of the code in your project. When you use VBA to create an Office solution, the code resides in modules, UserForms, and class modules within a Word template, Word document, or Excel workbook. When you use Visual Studio Tools for the Microsoft Office System, the code resides in classes and Windows Forms, which are compiled into an assembly, and is referenced by the Word or Excel document.

The Visual Studio .NET IDE has enhanced functionality, but it is similar to the VBA IDE in many ways. Each has an explorer for viewing projects, modules, forms, and references. Each provides a properties window, toolbox, object browser, and debugging capabilities. Table 1 lists some differences you might notice when managing your projects.

Table 1. Differences in the VBA and Visual Studio .NET IDE

VBA IDE	Visual Studio .NET IDE
Project Explorer contains a dynamic list of all of the projects (templates, documents, and add-ins) that are currently open.	Solution Explorer contains a static list of one or more projects in the open solution.
Project files are stored in subfolders: UserForms, modules, and class modules.	Project files are stored alphabetically and are not categorized into subfolders.
In Word, the project contains a folder that shows the references to global templates. In Word and Excel, external references are set using theReferences command on the Tools menu. If you create a Web reference using the Web Services Toolkit, classes are created for the Web service and all of its methods. The classes are located in the Class Modules folder.	The project contains a folder that shows the references you have set using the Add Reference command on the Projects menu. If you create a Web reference, the reference is located in the Web References folder.
Project files have distinct file extensions: UserForms (.frm), class modules (.cls), and modules (.bas).	Project files for forms, modules, and class modules all have the same .vb extension. Supporting files have other extensions (.xml, .aspx, and so on.).
In a VBA solution for a Word template or document, ThisDocument is located in the Microsoft Word Objects folder. In a VBA solution for an Excel Document, ThisWorkbook and the worksheets are located in the Microsoft Excel Objects folder.	Visual Basic .NET Word projects contain a ThisDocument code file. Visual Basic .NET Excel projects contain a ThisWorkbook code file.

Another difference that you will find is in the use of ActiveX controls. In VBA, ActiveX controls are top-level objects and have IntelliSense support. In Visual Basic .NET, you must define variables for the controls, use the FindControl method in Visual Studio Tools for the Microsoft Office System, and convert them to a strong type in order to access IntelliSense.

Security Differences

The Microsoft .NET Framework provides security features that you cannot take advantage of in VBA. In VBA, there are three basic security options:

• Set the security settings to high on user machines and digitally sign your code.
• Let the user decide whether or not to trust the code when presented with the macro virus warning.
• Set the security to low to allow all code to run (including malicious code). Note that this third option should never be used.

Word and Excel documents with managed code extensions that are created using Visual Basic .NET do not use Office macro security, which relies on the Office certificate store. They incorporate the standard security features available in the Microsoft .NET Framework 1.1, for example:

• Code signing is no longer necessary, as there are several types of evidence that are available for security in .NET Framework, including Application Directory, Strong Name, URL, and more.
• Administrators can use standard tools to set security policies. The security policy must grant full trust to an assembly or the code cannot execute.
• The end user cannot change security options within Word or Excel to permit untrusted code to run. If the end user opens a document with untrusted code, the code will not run.

For more information on setting security in the .NET Framework, read the Visual Studio Tools for the Microsoft Office System help topic, “Security in Office Solutions That Use Managed Code Extensions,” or see An Overview of Security in the .NET Framework.

Deployment Differences

Deploying Visual Basic .NET applications is quite different from deploying VBA applications. Visual Studio Tools for the Microsoft Office System projects usually consist of two files: the assembly, which contains the compiled code, and the document (Excel worksheet or Word document or template), which contains custom properties that point to the assembly. The document and assembly are deployed separately. Unlike many VBA projects where the code is embedded in the document, in Visual Studio Tools for the Microsoft Office System projects, the assembly can be stored in a shared network location, or it can be copied to each end user’s computer. The advantage in deploying an assembly to a network location is that it is easier to update the code because you will have only one copy of the assembly on the network share. Users can modify and customize their copy of the document and will have access to the updated assembly every time the document is opened. This happens automatically, with no user intervention.

In-memory Representations of Data

You can understand the features of ADO.NET by comparing them to particular features of ActiveX Data Objects (ADO).

In ADO, the in-memory representation of data is the recordset. In ADO.NET, it is the dataset. There are important differences between them.

Number of Tables

A recordset looks like a single table. If a recordset is to contain data from multiple database tables, it must use a JOIN query, which assembles the data from the various database tables into a single result table.

In contrast, a dataset is a collection of one or more tables. The tables within a dataset are called data tables; specifically, they are DataTable objects. If a dataset contains data from multiple database tables, it will typically contain multiple DataTable objects. That is, each DataTable object typically corresponds to a single database table or view. In this way, a dataset can mimic the structure of the underlying database.

A dataset usually also contains relationships. A relationship within a dataset is analogous to a foreign-key relationship in a database —that is, it associates rows of the tables with each other. For example, if a dataset contains a table about investors and another table about each investor’s stock purchases, it could also contain a relationship connecting each row of the investor table with the corresponding rows of the purchase table.

Because the dataset can hold multiple, separate tables and maintain information about relationships between them, it can hold much richer data structures than a recordset, including self-relating tables and tables with many-to-many relationships.

Note Data adapters, data connections, data commands, and data readers are the components that make up a .NET Framework data provider. Microsoft and third-party providers can make available other .NET Framework data providers that can be integrated into Visual Studio. For information on the different .NET Data providers, see .NET Data Providers.

Sharing Data Between Applications

Transmitting an ADO.NET dataset between applications is much easier than transmitting an ADO disconnected recordset. To transmit an ADO disconnected recordset from one component to another, you use COM marshalling. To transmit data in ADO.NET, you use a dataset, which can transmit an XML stream.

The transmission of XML files offers the following advantages over COM marshalling:

Richer data types

COM marshalling provides a limited set of data types — those defined by the COM standard. Because the transmission of datasets in ADO.NET is based on an XML format, there is no restriction on data types. Thus, the components sharing the dataset can use whatever rich set of data types they would ordinarily use.

Performance

Transmitting a large ADO recordset or a large ADO.NET dataset can consume network resources; as the amount of data grows, the stress placed on the network also rises. Both ADO and ADO.NET let you minimize which data is transmitted. But ADO.NET offers another performance advantage, in that ADO.NET does not require data-type conversions. ADO, which requires COM marshalling to transmit records sets among components, does require that ADO data types be converted to COM data types.

Penetrating Firewalls

A firewall can interfere with two components trying to transmit disconnected ADO recordsets. Remember, firewalls are typically configured to allow HTML text to pass, but to prevent system-level requests (such as COM marshalling) from passing.

Because components exchange ADO.NET datasets using XML, firewalls can allow datasets to pass.

The code you write for Access forms, reports, and controls targets the Access object model, but to retrieve data you need to use a data access technology such as Data Access Objects (DAO), or ActiveX Data Objects (ADO). The requirement for using two object models creates an interesting dichotomy when you’re writing applications for Access, which also sets Access apart from writing code for other Office applications,we should seperate between the presentation layer and the data access layer when we create an application with linked tables.

The DAO Object Model:
Data Access Objects, or DAO, has long been used as the native data access technology for Access. Originally included in the Jet database engine with previous versions of Access, new features appear in DAO for use with Access 2007.

The ADO Object Model:
ActiveX Data Objects, or ADO, is another data access technology available to use with Access. Both technologies are acceptable and can be used in conjunction with one another, although it’s probably not necessary to do so. DAO, as the native application programming interface (API) for the Access database engine, has performance benefits over ADO. That said, ADO is more generic and thus has its own benefits. For example, ADO provides the ability to create Recordset objects that are not bound to a table or query, but rather are created at runtime by appending fields. In addition, you can use an ADO recordset as the data source for a form, combo box, or list box.

Salam Alikom ,

ANSE-Tool : Access2.NET & SQL-Extensible Tool , Our tool has 2 functionalities … let me introduce both of them :

1. Access2.NET:

This is the first Functionality of our tool , we will take Access Project as an input and Extracts forms ; each form with its controls to be converted to .NET Forms “C# Win App”…. so that what is output ? Output is a Visual Studio Solution you can run it under .NET Framework and you can press F5 to debug .

Now…. you will ask your self… why will we convert Access Project to .NET Project ?

In Fact … i can say “FOR MANY REASONS”  the most important reasons of them:

1.We will Modernize Access Projects using .NET Technologies.

2.The converted project can be used to connect to SQL server which has better capacity rather than MS Access DB.

3.MS SQL reporting services or Crystal reports will be used to upgrade access reports to advanced reporting capabilities.

4.Upgrading legacy applications on Access will provide great value for future enhancements for the legacy application especially with integration capabilities with new solutions.

this is simple  introduction about 1st functionality and i will post description about 2nd Functionality “SQL-Extensible” Later.

i hope Access2.NET to be cleared for the reader ,

thank’s for your reading

Salam Alikom

Any Updates About Our ANSE Project will be posted here