In the ADOExpress Updates folder at:

http://briefcase.yahoo.com/bc/delphidb

Readme file follows.  If you have any problems getting it to work, please report
them here.

This is a replacement for the individual patches which were previously available
at this site.  It also includes a few additional fixes as well.

I will be moving the files to Code Central on the Borland Community web site
sometime next week (it seems to be down at the moment).

Mark

---------------------------- Readme.html --------------------------------

ADOExpress Patch Utility
========================

Last Updated: 11/6/99

From: Mark Edington
      Delphi Database R&D

This program will apply a patch to the ADOExpress source files to correct a
number of defects.  For a complete list of the defects addressed by this
patch please go to the Borland Developer Support Delphi 5.0 ADOExpress Defect List

http://www.borland.com/devsupport/delphi/fixes/delphi5/database.html#ado

Please note that defects fixed by this patch will not be available from within
the Delphi IDE or in applications that are compiled with the VCLADO50 runtime
package.

The patch program will only work if the original Delphi 5 ADODB.Pas file exists
in the Source\VCL directory.  If you have previously applied other patches
you will need to restore this file from the installation or your own backup.
If you have previously copied ADODB.PAS into the lib directory (as per my
previous instructions), then you should also delete that file as well.

The patch utility will optionally recompile the ADODB.DCU files (debug and
non-debug), so be sure to restart the Delphi IDE after the patch has been
applied.

If for some reason you need to restore the original unpatched files (saved
with a V50_Backup extension by default), the patch utility can to this
for you automatically.

This utility is being provided as an informal interim solution for ADOExpress
defects until an official update is made available from Inprise Corp.  No
availability date has yet been announced for an update.

If you have any problems using the patch utility please report them on the
Borland Public ADO Forum.

Hi Mark,

This is a much better way to patch ADODB.pas ........ :)
Thanks!

BTW: Do you have a fix or work around about
Recordset.AbsolutePosition speed when cursor location is Client?

--
Bobby B.
bobb...@writeme.com

Hi Mark,

I applied the patch, which did the necessary with the source code, but
nothing with the DCUs.
Have I understood it correctly?  Am I now supposed to move ADODB.PAS into
the Lib folder, so that it gets compiled when the dependencies are checked,
or was the patch supposed to create new DCUs that would look to Delphi like
the original shipped files?

Pete

Greetings :)

It's monday, the day when your brain works slower than normal.
I downloaded the new patch utility for ADO Express, and was pleased some new
ADO Bugs would go away.
Then I copied my original adodb.pas from my delphi cd, and executed the
patch. Great, no errors.

So i fired up delphi, and recompiled my project... darn.. all the old errors
where back.
But fear ye not, the patch utility works fine... just my brain doesn't ( on
mondays at least)

I had forgotten to make the adodb.pas file readable after I copied it from
the CD, so it was still marked as readonly.
Just wanted to share it in case someone else "stumbled" on the "problem" on
a monday.

Thanx for doing a great job Mark !
Could you add an error message in the next patch utility, telling you if it
couln't patch the file ?

Cheers :o)

news:804353$6lu5@forums.borland.com...

Yes there is a workaround of sorts.  It's Defect #72795.  When controls are
disabled (with the DisableControls method) the AbsolutePosition is not read from
the Recordset unless a call is made to read the RecNo property.  For the next
release, I may add some sort of option to disable this completely.  Not sure yet,
I need to think about it some more.

It's also worth noting that other calls in the InternalGetRecord method also have
a measurable affect on the performance (reading Recordset.Status and
Recordset.Bookmark).  So, as I've mentioned previously, if performance is an issue
I strongly recommend dropping down a level and using the Recordset object directly
to eliminate the overhead of these calls and other code.

Mark

news:806fnm$s216@forums.borland.com...

If you left the "Recomple" checkboxes checked then it should have recompiled the
.DCU files for you.  If there was an error invoking the command line compiler then
it should have given and error in the status window.  If the compile failed then
in your lib directory you will see adodb.v50_backup and adodb.dcu that are exactly
the same.  You might rerun the patch program, click the restore button and the
click the patch button again to see if you get an error message.

If the patch program fails to recompile the DCU then you can either copy the adodb
file into the LIB directory or add the SOURCE\VCL directory to your search path.

Here is the command line that is used to build the non-debug DCU file (assumes
c:\D5 install directory):

c:\D5\BIN\DCC32.EXE -uc:\D5\LIB -nc:\D5\LIB /$C-,D-,L- -V-
c:\D5\SOURCE\VCL\ADODB.PAS

You could substitute the path for your D5 install directory and see if it works
when you execute the command manually.

Mark

news:806jum$s277@forums.borland.com...

Thanks for bringing that to my attention.  Turns out this is a bug in the
TApplicationEvents component.  If you are using it, then the default application
exception handling gets disabled.  So the exception was being raised, but wasn't
being shown.  I uploaded a new version that fixes the problem.

Mark

'Lo Mark!

The patch prog still doesn't work entirely.  It always backs up the .Pas
files; it sometimes backs up the .Dcu files, but it never recompiles - even
though it says it has.
I used DCC32 direct, with the command line parameters you kindly provided,
and that did work!
I thought at first that it might just be my machine (NT4 Server, SP5), but I
had the same problem with my laptop, running Windows98.  In both cases
manual invocation was required.
Perhaps it's something to do with these being UK machines - different date
formats or what have you?  Whatever, it's very mysterious as I seem to be
the only person reporting problems (mind you, it does make me wonder if
there are any folks out there who, having run the patch and got the A-Ok
message, are now living in a fools' paradise believing they've got new DCUs
when they haven't)

In the meantime, can I trouble you for the Debug version command lines?

Kind regards

-Pete

Mark,

This patch sounds great.  Unfortunately when I run it it looks ok, it
has the correct paths, etc.

But when I select Patch, it brings up a dialog that says "Foo"

I have re-copied the adodb.pas (and marked not read-only).  This is
from a D5 Enterprise system in the UK

ADODB    PAS       185,252  11/08/99   5:00 adodb.pas

Any ideas what I am doing wrong?

I downloaded the patch this morning.

I tried disabling the re-compiles and it still just said Foo.  I tried
with and without Delphi running.

D5 was installed in default place on my C drive.  I did try
re-selecting the path, but still Foo

Best regards

Gordon

"Mark Edington (Borland)" <meding...@nolunchmeat.com> wrote:

news:3827fad6.7862085@forums.inprise.com...

My humble apologies.  I had some test code left over in there from the other
problem with the error not showing and I forgot to remove it.  Anyway it's fixed
now.  Sorry about the confusion.

Mark

Mark,

The new one worked fine.

I have still got a problem that frequently accessing a MS Access 97
MDB file using Jet OLE 4.0 drivers with MDAC 4102.  I have Access
Date/Time fields set under Access as Short time e.g. 11:23, and with
D5 I set these to be displayed as h:nn (which displays fine, I also
set input mask as short time.  Yet D5 insists the fields are Dates and
not times.

This is driving me crazy!

Is there any fixes pending for this that you can tell me about?  I
have a MDB table with a StartTime and an EndTime fields, identical in
all but name.  D5 Enterprise with ADO Express, accepts one is a time,
but the other it thinks is a date!!!!!!

Any help or pointers would be appreciated.

Thanks again for the patch.

Gordon

"Mark Edington (Borland)" <meding...@nolunchmeat.com> wrote:

news:38289770.2103678@forums.inprise.com...

Can you send me the mdb file with a couple of rows of dummy data?  You might try
opening the database in the ADOTest demo and goto the "fields" tab which will show
you the actual ADO datatype being returned.  If the fields are mapped differently
in ADOExpress then there must be some difference at the ADO level in the data type
information.

I think you can also force this issue using persistent fields.  Instead of
selecting "Add Fields" in the dataset designer you use "New Field" then pick
ftTime for the data type and type in the fieldname that matches the problem field.
Also make sure you specify fkData for the FieldKind.

Mark

Mark,

I have emailed this to you.  if you have not received it please email
me direct, so that I know your real email address.
gordon.wil...@cabot.co.uk

Thanks

Gordon

"Mark Edington (Borland)" <meding...@nolunchmeat.com> wrote:

Mark,

I tried again adding new fields with the same name as the date/time
fields, and it WORKED.

Must be something to being more awake (either me or D5).

As long as this continues to work, I can progress.

It would be worth adding this to the FAQ or support list in case
others have the same problem.  At least until a fix is available.

Best regards

Gordon

http://i3.yimg.com/3/91eff748/h/d7019bfb/aepatch.exe

Access forbidden from external hosts