I've written a small (8-10 laptops) point-of-sale system running over a wireless network, as an HTA that reads from/writes to an Access MDB located on a network share.
I need to use ADO - GetString and the user roster are not available with DAO.
I also need to use DAO - the MDB cannot be compacted with ADO.
I know that:
1) If the database backend is not an Access MDB, I should use ADO.
2) If the backend is an MDB, but I want to upgrade to SQL Server at some point, I should use ADO.
3) Within an Access application, or any other VBA/VB application, I should use DAO, as ADO must go through a translation layer of the Jet OLE DB Provider, while DAO is more direct.
4) VBScript/JScript allows me to use either DAO or ADO.
The two-part question is as follows:
1) In this software environment (HTA/scripting), is it better to use ADO rather than DAO?
2) Does ADO offer any benefits because the HTA is reading/writing over a wireless network?
If the only reason you need DAO is to compact the database, you can use DAO for that, and use ADO for everything else. You are not limited to using only ADO or DAO.
The biggest benefit of using ADO is that it will be easier to move to SQL Server Express when the time comes. You should do that sooner rather than later, as SQL Server Express offers all of the benefits of MSAccess databases without the drawbacks. SQL Server Express is free, and it will easily handle the system size you are proposing.
Access databases corrupt easily in a multi-user environment, especially when a wireless network is involved. If you are worried about losing the benefits of working in MSAccess, you can still attach to SQL Server using linked tables, and work with your SQL Server Express database that way.
You can also use JRO to compact your MDB file. This will be included with any recent version of MDAC, installed by default on XP and later systems. No installation of Access is necessary.
To answer your specific questions:
1) I would opt for ADO just because it is more current, and the same API can be used in other kinds of scripting, like LDAP/ActiveDirectory access, reading file system folders, reading MAPI mail, and working with other types of semi-structured text files like fixed width text and CSV. It's not specifically better for the HTA programming environment, but its perhaps better for you to learn a more widely applicable API. I also thinks it's an easier API to work with, but I started with it and only later worked on some older DAO projects.
2) One possible benefit that ADO provides is that of disconnected recordsets, which may have an advantage or at least suggest some architectural alternatives in your wireless network setup. You open a recordset, then disconnect it, so you can still work with the data in memory, but not have to leave a database connection open. Then at a later time you can reconnect and update the database. Also, you can work in a fully disconnected style by managing tables as local XML or ADTG files.
You might shoehorn DAO into working from VBScript but that's an odd pairing. ADO makes the most sense in general.
Another advantage of ADO would be that it supports RDS over DCOM or HTTP. This can be used to overcome many of the limitations of Jet MDBs used via file sharing, such as the corruption unreliable networks and clients can lead to. It also cuts the amount of traffic over the network, improving performance. In addition it offers a middle tier in which business objects can "live" and all of this can be mediated using COM+ where applicable.
Of course you no longer have the option of using a simple P2P network and a file share to host the database. RDS needs a server to host the process and run the Jet engine, which no longer needs to run on each client system. This means you can use Jet stored procedures that run on the server, offloading more client processing and network traffic. While not as sophisticated as T-SQL or other alternatives, this ADO/Jet 4.0 OLE DB Provider exclusive technology offers tangible benefits that can't be had using DAO.
RDS can mask much of the process of using disconnected Recordsets, simplifying client code. It uses ADTG under the hood, which was developed and optimized for this very purpose.
However using RDS requires more infrastructure and expertise than a simple file share. You might as well look into a low-end version of SQL Server.
In general I'd recommend using the jetcomp.exe utility to compact and repair, over either DAO or JRO. It offers a number of advantages.
If you can afford to use a HTA application with Access instead of a more performant platform, I would say you should go with the easiest api for you. The bottleneck will never be the abstraction of db access in your case. Still, DAO is really old.
Related
I am currently creating a vb.net program in which users upload a song file to the program and then it is saved within the programs files. I have set up the actual saving of the files but would also like to store some meta data of each in a SQL database within my program.
I have looked online and although i now understand the basics of SQL, im still a little fuzzy on how you actually implement this within VB.net. I have already added the library- Imports System.Data.SqlClient but failed to work out how to begin coding in SQL.
The basics of what im trying to acheive is a if statement that will determine wether or not a SQL database has been created in a specific location, and if it hasnt it should create it.
All constructive answers appreciated, thanks.
There are a number of different database engines available. The namespace that you have chosen contains the ADO.NET client classes for Microsoft SQL Server. You would use a connection string to specify how to connect to the database. This would often contain connection information, such as server name, user name, password etc, but it sounds like you want to store data locally.
There is a local version of SQL Server called LocalDB, but I think you would still need quite a lot of the SQL Server components installed for that to work. Although you can package these with your application they may be too large for you, so you may want to look at SQL Server Compact Edition, which is much smaller and allows you to package the whole engine as part of your application and is useful for storing data locally. Compact edition doesn't have quite all of the features that LocalDB does, so you may want to compare the features available for each.
Although you can use the ADO.NET objects to connect to a database, I think most people these days would use a layer on top which transfers data back and forwards between objects in memory and the database. This also allows you to use Linq to query the database in most cases. I personally use Entity Framework. You might want to look into that. There are different ways of configuring EF so you may want to look at a tutorial. Once you have it set up, you will probably find it much easier and safer to work with than writing SQL manually though.
We have a 3gb file of data from our propriartary CRM system which is using SQL as a database.
The CRM is not meeting our needs and we are thinking about moving to Microsoft access and building our own system from the start.
We were wondering if it is possible to easily migrate the SQL database into access?
Thanks for your time.
First of all, it has been a long time since I've had to use MS-Access (thankfully) but I'm not sure Access is suitable for databases of that size. In my opinion, it's best suited to small, desktop-type applications with few concurrent users.
To answer your question, I believe Access offers a data import feature(see under the External Data ribbon in 2013) - though I'd suspect it might balk at the idea of 3GB of data. Edit: Actually this link suggests the max databsae size is 2GB
What might be more useful however, is its Linked Table feature. If I remember correctly this allows you to access data stored in SQL Server (or a similar RDBMS) which is more suited to large volumes of data through an Access front end - complete with pre-canned forms, queries, reports etc..
It is possible and fairly straight forward to move all of your data tables from SQL Server to Access; however, SQL Server is a much more robust database engine than Access. I would highly recommend against that. I have however had very good success using Access (ADP project files) as a front for the interface and using SQL Server as the database back-end for simple to moderate complexity interfaces. If you are not getting the performance you desire from your SQL Server, you might want to consider query performance tuning and looking into memory and hardware upgrades first. I think you will get better and faster results from doing that.
The simple solution would be to “link” Access to SQL server. That way you continue to use a robust data engine, but are free to use all the reporting and coding features of Access.
In this setup then Access simply becomes a “front end” to the existing SQL database.
And you do NOT want to use an ADP project in Access since they are depreciated.
The process is thus to create a blank standard database, and then use linked tables to SQL server. This will not only eliminate the need to import data (which is likely changing all the time).
Im interested to find out what techniques developers are using to connect to a Windows Azure instance running in the cloud?
From what i understand it is very similar to SQL Server with two of the key differences being Multiple Active Recordsets are not supported and idle/long running connections are automatically terminated by azure. For this microsoft suggest incorporating retry logic in your application to detect a closed connection and then attempt to complete the interrupted action. Does any one have example code that they are currently using on this?
To build out the data layer i was looking at various ORMs. Since im going to be accessing azure from windows azure (ie seperate boxes) to me it would seem key that any ORM mapper would need to support asynchronous methods so as not to block any windows azure instances.
Any suggestions as to which ORM mapper to use, or comments on what you are currently using
I have successfully used NHibernate with Azure and we are in the process of building a commercial app on top of NHibernate. The only problem that I had was with the connection pools when running locally and connecting to SQL Azure in the cloud - which was fixed when turning connection pooling off.
You may find similar problems with other ORM's... SQL Azure is less patient (for obvious reasons) than most people are used to. Connections timeout quicker, recycle sooner and so on.
Test first!
Here's one specifically designed for Azure:
"Telerik recently announced the
availability of Open Access, the first
ORM that works seamlessly with SQL
Azure relational databases in the
Windows Azure cloud."
And a few commenters at the Azure User Group recommend LLBLGen and Entity Framework.
I've been using Entity Framework - runs without any problems, just a different connection string.
What you do have to think about is your connection strategy, and how efficient your queries are. I've got method that's easy to write in EF - I've got a new record that could be duplicated, so I check if it's there, and if not, add it.
EF makes it really easy to do this, as if you're just accessing a local collection. BUT ... if you're paying for your dB access because it's in Azure and not on your local network, hmm, maybe there's a better (aka cheaper) way of doing that
According to Ayende, NHibernate "just works" with SQL Azure.
We have been using NHibernate without any customization on Azure (indeed, it just works), you can check Lokad.Translate as an open source example of such use.
I've started to build a Windows Forms application. The application will work in two different modes:
local (1 user, opening and saving files just like a Microsoft Office application)
network (multiple users, all accessing a shared database in another host of the network)
For the local mode I am planning to use a SQLite embedded database, I've made some tests and it worked very well. For the network mode I'm thinking about SQL Server Express. Both solutions are free.
Now I'm worried about architecture best practices for this app. I usually split my application layers in 3: Presentation, Service (or business logic) and Data Access.
In your opinion, what are the architecture "best practices" for this kind of application, specially considering the data access layer in those 2 modes (local and network)?
For example, should I create one DAL class for local and one DAL class for network, and build a factory for them? Do you think nHibernate would work for this scenario (then I could use the same DAL class for both local and network modes)? Can you see better options for the database solutions I've chosen?
I appreciate any advice, hint, example, suggestion :)
Thanks!
If you use NHibernate, you can create your application any way you want. Plugging in a different database is just a matter of configuration.
By the way, i would prefer using MS SQL Server CE for the local database, because it is more compatible with MS SQL Server.
My database must be updated at arbitrary intervals, manually, with new info to put on standart tables that don't require structural modifications. one app will update the database.
Another app, the one I will distribute (to friends and family only, but doesn't require any security feature to it, like encrypting the database) will read the database and use its data on labels, listviews, etc.
The problem is, I'm the perfect definition of full-fledged n00b at programming of any sort, and still don't know what database to use.
I thought that I should use a SQL CE (*.sdf) file, and store that database thing on an FTP. then, I could download it and get data from it everytime the "client" app runs, and certain button ("connect") is clicked.
After some hard-core googling, I found out how to connect to the sdf thing, using this connection string:
Provider=Microsoft.SQLSERVER.CE.OLEDB.3.5;Data Source=D:\Documents and Settings\Camilo\JCTM.sdf
So it connects, or at least didn't show any error.
I don't know if it's a good idea to use sdf SQL CE files as databases, if it's too hard maybe I should go for XML? what do you guys suggest, what is the easiest way to implement very simple databases in VB.NET?
By simple databases I mean:
- no search needed
- no advanced features except storing strings on tables with columns and rows
- easy to access, read, edit, etc. by different VB.NET apps
Is sdf a good idea?
I would recommend Sql Server Express Its free and can be redistributed with .net applications as part of the install process.
The challenge will be syncing the changes between the different clients. If you have access to a FTP server, you may have the ability to host a website in IIS. If you can do that you can just use webservices and read against one database instead of copying one local.
Luckily for you, you can abstract away the need to be concerned with which back-end database you use to store your data.
Technologies such as ODBC (Open Database Connectivity) and OLEDB (Object Linking and Embedding, Database) allow you to limit your concern for the backend datastore to the task of crafting your connection string. In your example, the connection string says, "I'm going to connect to a SQL Server CE database via its OLEDB provider, and it's physically located over on D:/...
Within the code, you use standard OLEDB mechanisms to access and manage the database. Because of this abstraction, you can use OLEDB providers for SQL Server, Oracle, XML, Access or comma delimited text files as your backing store if you wish, and the only change you need to make to your code is the connection string. Your choice then should be to pick the database that you have the tools and know-how to set up and manage initially.
I'd start with Microsoft Access because it has its own UI, and can play well with .NET.
You can also try the ADO.Net implementation for SQLite, which I've also found very useful.