| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.tools -> Re: decompile option in access97
I didn't know that the accepted practice was to split the code and data into two "databases". I don't want to have the data separate from the code. Since I'm having to compact the database on a daily basis, It'll just confusing for some people and this application need to be able to be simple enough so a person can press a simple button and a few days later run another program somewhere else and not worry about databases (yes, it's got to be that simple) I guess if I wanted to develop the application separate from the database, I'd use ODBC or MySQL to store the data or even my own text or binary files, but they don't have the encapsulation that a single access file has.
And as for the crosspost, I wanted to get a feel for what types of "corruption" problems others are having. I don't think that just switching to Oracle will solve the problem since VB isn't an option there, etc, etc, etc.
And on another note, I've been expirimenting with writing binary files and trying to read them in C using structures/record types in both and haven't had much success. Have you had any success using binary file i/o accross different products like that?
Thanks,
Jeff.
"Michael (michka) Kaplan" <former_mvp_at_spamfree.trigeminal.nospam.com> wrote
in message news:#WY90j19$GA.288_at_cpmsnbbsa09...
> Are you saying that you have combined all of your data into a single MDB
> file instead of two separate files, one with the data and the other with
the
> program?
>
> If that is the case, then try splitting them. This is a standard, accepted
> technique that has been in widespread use at least since Access 2.0.
>
> And why crosspost an Access question to SQLServer and Oracle groups? All
you
> will get is a bunch of "don't use Access, thats the problem you are
having"
> which serve no real point. Either you want to solve the problem, in which
> case stick in Access groups, or you want suggestions on where to go to.
>
> --
> MichKa
>
> random junk of dubious value at the multilingual
> http://www.trigeminal.com/ and a new book on
> i18N in VB at http://www.trigeminal.com/michka.asp
>
> "Jeff D. Hamann" <hamannj_at_ucs.orst.edu> wrote in message
> news:8lnrpl$bto$1_at_news.NERO.NET...
> > I tried to decompile an access database and got a messasge that there
was
> > too many nested if statements ( or loops or something) and found this
(mess
> > below) in the vb source code for one of the modules .... needless to
say,
> > all the code in the module is toast and thank goodness I have a backup.
My
> > database grows from 20MB to 850MB over the course of a couple of days
(lots
> > of scientific data and computations) and with each run I have to empty
out
> > the tables and repopulate them with another dataset with different
> > assumptions. Is this (corruption) common? These types of problems are
making
> > me lose faith in MSOffice and my confidence in Access as a rought and
ready
> > database package is shrinking by the day, especially when I have to earn
a
> > living on reliabilty. Has anyone else run into this? I know this might
not
> > be the best place and I don't want to start a flame war (at least not at
me)
> > but If I were going to pick the most stable database in the planet (any
os,
> > any vendor or opensource) what you people suggest?
> >
> >
> > Opti
> >
> > ' t
> >
> > f R
> > 'S:BUI
> > ""# NO
> > "<~J^2 e?Zì3W ¿ s_rÿÆ c £
> > '`, lÂGremova~lIabj à , _ÿâ"Íh© ? â 0i ? d Ã
> > exporÀt curr¡¨À« di s by Âd`.rict¦_ª C _harves
> > <â EXPORT°_YIE ¥ã¤.ü ÁK finis` £ AjEuns c Ól~eàØlxj ,|5 C0loseÁÀ!3'
ÛÃ bÆ
> > bÆ!ÏE`ÔÀÒ A Ï o ? ht40G ßÏ Â y / " r # ? ¹
> > '/*
> > Y in d Á ¯8 8BRANCH,_? METERÿ8ûÿ8± %LÀº
> >
> >
> > --
> >
> > -----------------------------------------------------------
> > Jeff D. Hamann
> > 2601 NE Jack London Street #27
> > Corvallis, Oregon 97330 USA
> > 541-740-5988
> > hamannj_at_ucs.orst.edu
> >
> >
> >
> >
>
>
Received on Wed Jul 26 2000 - 00:00:00 CDT
 |
 |