Text databases (.tdb) Info?

[shartken]

Does anyone know anything about .tdb files? I think they are called text databases, and my knowledge of them were that they were first developed for UNIX systems in the 80's.

Could some tell me what are the advantages/disadvantages of .tdb databases versus a database engine, such as mySQL or Interbase? Are they more stable, can they support more users, can they hold greater records, or are their no licensing issues?

[doctorgonzo]

I don't know anything about TDB, but it appears that a website is here: http://www.ar.com.au/~crook/tdb/

It appears to be a non-relational database, so it wouldn't be appropriate for complex data. It is free.

[mairving]

TDB is actually Trivial DataBase, not Text Database. It is used for small quick databases generally. Samba 3 uses .tdb files to store mock registry records on 'nix systems. They are binary not text.

[shartken]

Thanks for the info. The reason I'm asking is because I'm working with some bloatware for a client, and I'm talking with the developers. Their paying a lot of money for contracts and licensing, and I think they're getting a raw deal.

The database engine is Access, believe it or not, and they're running it over a 5-10 user enviroment with very sensitive client information. It looks like its something someone slapped together in a back office somewhere.

So I'm guessing you guys wouldn't recommend this for an enterprise level application like this. I'm suggesting a Linux/Apache/mySQL solution, or a Win2k3/MS SQL depending on their preference. Your thoughts?

[mairving]

No, I wouldn't recommend it even if you could get it to work since I don't think PHP supports it. MySQL is a very robust database and will work very well in this case.

[doctorgonzo]

I second the Linux/mySQL alternative. Been there, done that with Access.

[shartken]

Thanks, now I got another question:

Would opening a database and applying a replica set in Access affect how the front end application performs and its functionality? A couple months ago, I opened the .tdb database in access, and replicated it across some laptops so my client can go remotely in the field and work, and then come in the next day and update their work with the server.

The application has been running great. No performance issues, no corruption, and it compacts and repair just fine. But I just got a call yesterday from the client saying they've just got a new software package that's suppose to work with it (it runs off a .mdb database) and they're getting an error. They said also that the program links up with Quickbooks, and this can't be done either.

Unfortunately, they called the technical support, and the third party tech support is squeling like a pig that replicating the .tdb database ruined the program, and that it can no longer link with other applications. I say that replicating it shouldn't affect the functionality with other programs, since it is just exporting a formatted text file, and if the tables are linked in the new .mdb database the replication shouldn't matter.

The tech sounded to me he was just trying to get us off the phone. He said some questionable things, like it is impossible to import delimited data through the back-end via Access if the keying structure was known, and he also dismissed a PHP-mySQL application into a viable solution. He bullied the client to go back to a four month old, non-replicated database and reenter pages of records! Its guys like this that gives the IT industry a bad name!!

Could you guys please give me your thoughts on the possibility of an Access replication interfering with other "linked" applications (I think they just export a simple text file, but they might have linked tables) as well as what is the best thing, in practice, to do when a competitor butts in, bullies the client, and makes them loose faith in you.

Thanks!

[doctorgonzo]

Could you describe your setup in detail? Particularly when you talk about opening up a ".TDB file" in Access. What kind of file is this? Where did it come from? How did you open it? Did you import the data or what?

[shartken]

The program itself is used for job tracking, agent scheduling, and customer service. It runs just like your standard business CRM software that was coded in Access.

I just opened up Access, then I went to file->open, changed the association to all files, and opened the .tdb database.

From looking at it, it looked like it was authored in Acces. It was made entirely out of about twelve tables, and the only application specific, non-data tables were for reports, and they just contained SQL code. There were no macros, codes or queries. Also, normally, the application would leave a .ldb file, and their is a compact/restore button right there on the application which means its running the Access engine IMO.

Everything opened up fine and closed down fine after opening the .tdb file in Access. I tested the application, and it ran fine with no performance or functionality issues. I tested it both locally and across the network with no noticeable events.

I then created a replica, with the design master on the server and remote databases on each laptop.
I changed the primary keys from autonumber to random in case the client enters a job at the design master and has a remote agent enter it onsite.
I created a query, in case this event happened, to delete the less detailed entry, as well as alter the primary keys into a logical order.

I tested the app, and it ran fine, and it has been running fine every since

I had the client update with the design master and run the query after each offsite job every morning, and compact/repair every week. Everything has been going good since this past week when they tried the new software. I even compacted/repair today, it ran quick, so it wasn't even corrupted.

I wish I could tell you more, but I think it boils down to that there are few ways you can share data in an Access project, you can point the application to the database directly, you can link the table (which is just like doing the first one), you can create a replicated set, or you can export into a formated text field and import it into the app directly.

From my knowledge, with the proper design and preventative procedures, you can link, export, and directly access a database that has undergone replication with no data corruption or performance loss. Replication changes that cause errors in the past are associated more with the limit on nesting (7 to 6), and the total number of allowable fields (slight decrease, but still well over 200). I know there are some changes that affects record size, but for a good app this shouldn't be a problem.
Is there something I'm missing?