Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

vb backend database

Status
Not open for further replies.

DebbieCoates

Programmer
Oct 2, 2007
23
0
0
GB
I am using vb at the moment to connect to SQL Server, and previously I have used Access to connect to SQL, however what if you want to set up a standalone database for someone who has no backend database? Is there some sort of data store that you can wrap up with the vb .exe application?
 

Or, esp. if you are already using SQL Server, something like SQL Server Express 2005, or MSDE 2000: Sql Server.
 
Finally, you can simply use xml files and the recordset's Save method.
 
Sometimes there is something to be said for "low-tech"!
 
Why on earth would anyone want to do that, Bob? If one were to stick a toe in the XML swimming pool, why not just jump in and go all the way with XML--or am I missing something?
 
Sorry, I don't get your analogy. Can you elaborate on what you mean?
 
I admit, that was badly phrased.

I'm trying to figure out why you'd save a recordset as XML. Presumably you'd also be manipulating it as a recordset, and using XML only for storage when the program isn't active. If you're going to save the data as XML, why wouldn't you forget the recordset business entirely and parse your file as XML and manipulate it with XML object methods?
 
You have two formats available for persisting ADO Recordsets, XML is just one of them.

I don't see a reason to get hung up on the actual data format. That's like saying Why use Word 2007, why not manipulate documents with XML object methods? just because Word 2007 can write documents in an XML format now.

It also lets you program using ADO's object model and the normal approach you'd take to working with data in a Recordset.
 
That's like saying Why use Word 2007, why not manipulate documents with XML object methods? just because Word 2007 can write documents in an XML format now.
Not really.

I'm not hung-up on the data format, and I don't generally advocate using XML as a substitute for a database. What did bother me here was the paradigm mix, which might tempt the programmer to include elements of both object models. This would have an impact on performance (neither ADO nor XML are lightweight) and would turn into a maintenance nightmare.

But I do see that a simple, save-as-XML method in itself would be an easy solution. I've just been around too long to trust that that's all it would be.
 
<If you're going to save the data as XML, why wouldn't you forget the recordset business entirely and parse your file as XML and manipulate it with XML object methods?

One of the big reasons would be that using XML parser to handle data manipulation pretty much curses you to use XML as a back end forever, whereas you could move up to a heavier-duty DBMS fairly easily if you use ADO for the data maniuplation and XML only to persist data.

Personally, I like to use ADO better than XMLDOM. I know it better. I also like the cursor capabilities, the ability to create dynamic indexes, and the like.

[soapbox]
One of the big selling points about ADO recordsets when they first came out is that they were able to access non-relational data. One of the ideas behind this was that there were vast stores of non-relational data on the internet. As time progressed, this capability on the part of ADO recordsets was downplayed since most of the time they were used to access RDBMS's, and further downplayed with the ascendance of XML and the DOM. However, the ability for ADO Recordsets to do this is still there, and IMO can be usefully leveraged to use well-known methods to access and manipulate XML files.

 
I get (and appreciate) your points, Bob.

I worry about the giant crowd (seems to be university-driven) that is h&ll-bent on forcing all types of data problems into XML.

Then there are outfits (viz Apple) that can't make a decision and do both at the same time. ("Hey, why is iTunes so slow to start-up, and why does it use all my memory?" Sheesh.)
 
Yeah, there is that too. Like anything else, there has to be some up-front preparation and direction, or things get out of hand...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top