From: Ivar on
> What did you use? XML? Flat text files? Binary files?

Sequential or random TextFiles instead of databases. Classes, collections
etc instead of recordsets. Printer object instead of reports, Picture boxes
instead of ListViews and grids.
More code involved, but just as fast and so so so much more control.

Ivar


From: MikeD on

"Ivar" <ivar.ekstromer000(a)ntlworld.com> wrote in message
news:OdIqf.17884$b4.8395(a)newsfe1-win.ntli.net...
>> What did you use? XML? Flat text files? Binary files?
>
> Sequential or random TextFiles instead of databases.

Random (I assume you mean random-access) text files? Never heard of such a
thing.

Sure, you can use a random-access file, but it wouldn't be a text file. Open
such a file in Notepad, for example, and you're going to see a lot of
gibberish.

--
Mike
Microsoft MVP Visual Basic


From: Anil Bhattacharji on
Hi ,
You can create a random access file anyway you want . It can have a CRLF
ending and the record can be written using the Print statement. So it will
not necessarily be gibberish.


...


From: MikeD on

"Anil Bhattacharji" <nothing(a)nowhere.com> wrote in message
news:efGrvq2BGHA.676(a)TK2MSFTNGP10.phx.gbl...
> Hi ,
> You can create a random access file anyway you want . It can have a CRLF
> ending and the record can be written using the Print statement. So it will
> not necessarily be gibberish.

Granted, it's been ages since I've used random access files, but I don't
think you're correct. Maybe you're thinking of something different than I
am. I'm talking about using VB's Open statement to open (or create) a file
using Random mode. This creates a file with "records" and you use a
user-defined type to define the record. You use the Put statement to write
to the file and the Get statement to read from it. I've never heard of using
Print (I assume you really mean Print #) to write to such a file. The Print
# statement is used to write to sequential files.


--
Mike
Microsoft MVP Visual Basic


From: David J Mark on

"MikeD" <nobody(a)nowhere.edu> wrote in message
news:%23ekUvf0BGHA.216(a)TK2MSFTNGP15.phx.gbl...
>
> "Ayaz" <Ayaz(a)discussions.microsoft.com> wrote in message
> news:D66A22D8-9564-44EF-B9E5-7FF619C906D2(a)microsoft.com...
>> Hello, i am creating a system where i add, amend and delete data from my
>> database. i have been looking at vb6 and ado and dao. i have been told to
>> go
>> for ado objects such as recordsets and connection. (adodb).
>>
>> I have used VBA before and have managed to create a system using it. I
>> have
>> used my vba code to create the following program in VB6 - with slight
>> adjustments. but it worked!!
>>
>> My question is: i have looked at the coding for adodb - and it does
>> require
>> more than what i did with the program below. what is the advantage of
>> using
>> adodb compared to how i coding the program below? should i code my system
>> using the code below? - obviously i will implement error checking and
>> validation etc.
>>
>>
>> i was just checking whethe the code that i used for vba would work in
>> vb6. i
>> dont know what to do, im a little confused. stick with this method or
>> turn to
>> adodb objects? all i want to be able to do is add, amend, delete
>> products,
>> suppliers, users and so on.
>
>
> Your posted code is using DAO. If your database is Access AND is going to
> remain Access for at least the forseeable future, I'd recommend staying
> with

No. You do not want to use DAO with Access or anything else at this time.
ADO is the way to go.

> DAO. One reason is that you're apparently already somewhat familiar with
> it. A second reason is there's no advantage that ADO is going to give you
> for an Access backend database. In fact, DAO is slightly more efficient
> than ADO with Access databases.

This is not true. It all depends on the code and queries. Granted that
most VB/DB code is so God-awful that the database layer doesn't matter. If
you really want to open recordsets and seek through them, etc. then ADO is
not going to help.

>
> Now, if you might upsize your Access database to something else in the
> future (SQL Server, MSDE, Oracle, MySQL or whatever), then ADO would be
> the way to go since it will make things much easier for when you do
> upsize. It's very possible there would be little (and maybe no) code that
> you'd have to change, other than specifying a different OLEDB Provider
> and/or connection string.
>
> Are you even more confused now? <g>
>
> BTW, have you previously posted under the name Pinto1uk? Lot of
> similarities between this post and posts made by Pinto1uk. If you are the
> same person, then again I recommend you visit your local library or
> bookstore and get a decent book on database programming with VB6.
>
> --
> Mike
> Microsoft MVP Visual Basic
>
>