|
Storing information - VI External devices
There are a lot of external devices where you could store your data. Electronic diaries, watches, mobile phones, handheld devices are currently in a position to communicate directly with Windows over a serial port or some other link. This opens up opportunities for more sophistication in your application development process.
For example, if you save a new appointment or task using Outlook programming, you could also save it simultaneously to a digital watch or an electronic diary.
SQL Server Database Published on CD
Using SQL Server, a complete database can be published on a CD. This is a very useful feature when you want to publish large amounts of read-only data on a removable medium. All other removable media like tape devices or ZIP drives may not be accessible directly and may require you to restore data from them on the hard disk. However, CD based database publishing provides this excellent ability to be able to read a database directly from a CD.
To create a removable media database, you create the database using the sp_create_removable system stored procedure rather than using SQL Server Enterprise Manager or the CREATE DATABASE statement. The sp_create_removable system stored procedure creates three or more files:
A file containing the system tables.
A file containing the transaction log.
One or more files containing the data tables.
Even though the database itself is likely to remain on the read-only media such as CD-ROM, the system tables and transaction log are placed in separate files on writable media so that management tasks can be accomplished, such as adding users to the database, granting permissions, and so on.
After the database has been created, you can use the sp_certify_removable system stored procedure to ensure that the database is configured properly for distribution on removable media. If the database is configured correctly, the database is placed offline, allowing the files to be copied to the removable media.
Mailbox custom properties
Exchange server mailboxes are a server-based e-mail storage mechanism. There are a lot of properties associated with a mailbox. The display name, alias, full name, Windows NT account are some of these properties.
Generally, in an organisation, each mailbox represents a user or employee. In addition to standard properties, Exchange also allows many custom properties to be specified. These custom properties, if used consistently, can be utilised for storing information which is related to each user (mailbox). These properties can be used in workflow, messaging, collaboration and related applications.
The new version of the directory--Active Directory--integrates the mailbox properties with the Active Directory schema. This unifies the file system and messaging system directory information and simplifies usage of properties.
To specify custom properties in Exchange, start Exchange administrator, choose a mailbox and view the properties.
Word VBA containers
Word for Windows has a programming shell based upon Visual Basic for Applications (VBA). This shell provides complete control over all the features and functionality of Word using VB syntax.
This object model has a special collection called Variables. This collection can be used for storing and retrieving information along with a standard Word document. When you are using Word as a programming tool, you may want to store some state information or positional information about your application permanently.
Here is the code to add a variable to the currently open document and store a value in it:
activedocument.Variables.Add "sample", 19
?activedocument.variables("sample").Value
19
When you save the document and reload it, this value will be retrieved for you automatically.
Cookies
A cookie is a piece of information that the client stores on behalf of the server. In this case, the information stored in the cookie originates at the server, and is returned to the client as part of the server's response to an HTTP request.
A client may have many cookies stored at any given time, and each cookie may be associated with a particular website (or page). Each time the client visits that site, the browser packages the cookie with the HTTP request. The Web server can then use the information in the cookie to identify the user, and, depending on the nature of the information collected, possibly even personalise the appearance of the Web page. It can also add or change the information within the cookie before returning it.
All cookies have an expiration date. If a cookie's expiration date is explicitly set to sometime in the future, the browser will automatically save the cookie to the client's disk. Cookies that do not have an explicit expiration date are only good for the life of the browser session; as soon as the browser is closed, the cookie is erased from the computer's memory.
Because a cookie is sent back to the server with each new request, cookies are an ideal way to identify a series of requests that come from the same user. When a request is received from a known user, the unique identifier can be extracted from the cookie and used to retrieve additional user information which is often more sensitive or private, from a database. That way, the user's private data is kept safely on the server, and not in the cookie where it could be hacked. The cookie only contains the key to the private data stored on the server.
When a request is received with no cookie, or with a cookie that does not contain the necessary identifier, the request is assumed to be from a new user. In that case, a new identifier is generated before the response is sent back to the client, and a new record added to the server's user database.
ADTG files of ADO
Active Data Objects are a new method of handling data. This is more advanced than traditional DAO or RDO methods used in Visual Basic.
ADO allows a client to access data from server. This data can be from a remote or local database or provider. The data, in the form of records, is returned as a recordset containing rows and columns. The recordset can be editable or read-only, depending upon certain settings specified while retrieving it.
Once the recordset is retrieved, it can be edited and the updates can be applied to the original data.
In some cases, you may want to store the data locally for future reference or a delayed update. Normally the recordset would be destroyed when the user session terminates. To persist the data into a permanent storage you need to use the Save method of the ADO recordset object.
Here is to code to do this.
dim cnn As New ADODB.Connection
dim rst As New ADODB.Recordset
cnn.Connectionstring = "provider=SQLOLEDB; _
data source=mysql; uid=sa"
cnn.Open
rst.CursorLocation = adUseClient
rst.Open "SELECT * FROM authors", _
cnn, adOpenStatic, _
adLockBatchOptimistic
rst.Save("myfile.dat")
rst.Close
rst.Open "myfile.dat", , , , adCmdFile
Using system menus programmatically (Visual FoxPro)
Visual FoxPro (VFP) has a list of system menus that are internally defined and are usable when you define a menu. For example, you may want to provide a text search-and-replace facility in your own application. Your application menu is already created. Here is how you incorporate the existing functionality provided by VFP menus in your menus. You can use the same technique for standard menus or for shortcut menus.
Here are the steps:
Create your custom menu.
Let us say you want to insert the Find dialog in your Edit menu
Choose the Insert Bar... button.
Select the required menu bar from the dialog and choose the Insert button.
Now generate the menu and run it.
The menu will not only have the Find option, it will also provide the complete dialog for the Find functionality without you having to write any code. Incidentally, this Find option can work with any kind of text field on screen, including the edit region or an open memo.
Now if the reference to the Find option was not present in an active menu or if the active form was modal, this Find functionality would be unavailable.
Using VFP System Menu Items Without Defining A Menu
It is possible to use these menu items without defining a system or shortcut menu. For example, you may want to provide a button called Find... in a form to invoke the Find dialog. Here is how you do it:
Create a form. Then create a button called command1 and write the following code in the click event:
=SYS(1500, '_MED_FIND', '_MEDIT')
The exact names of the system menu options vary with the version of FoxPro. Please refer to the online help within the System Menu Names topic for the exact syntax of the names of system menu bars.
|
