switched from Novell to Citrix now keeps getting corrupt

G

Guest

For starters I learned what I know about Access on my own to build the
database I am writing about so my knowledge is minimal.

About 2 years ago I created an Access database which has worked great for
those 2 years until about a month ago when we switched from Novell to Citrix.
Ever since then the database 'corrupts' multiple times a day requiring all
users to exit then repair execution which seems to fix it temporarily. The
error says something like 'this is not a Microsoft Access database or the
data is corrupt'.

I tried moving the data to a copy I have but the problem continues so I feel
the problem is not with the database itself but with the change to Citrix. In
researching this I can see changing to Citrix could very well be the issue
because of multiple reasons.

My work environment is a large university campus so I have to work with our
computer support for any network or server issues and we have many people in
my department using the database who have already become frustrated with the
whole mess so I am asking for assistance in fixing this as efficiently as
possible. If someone can give me a list of sorts of everything I need to
change now that we use Citrix I would be extremely appreciative.

As I see it, there is an issue in the fact that I knew nothing about
splitting the database between front end and back end. Will that change alone
fix my problem? Is there an article on how to make that change?

Also apparently there is an issue with OpLocks? Is that always a problem or
only possibly? Some users may have switched to Windows XP or something. I am
not sure. Is fixing this extensive requiring help from my IT department?

I get the feeling there may be many more issues and would appreciate any
thoughts on possible problems. We are almost to the point of just trashing
the whole thing and trying to figure out a different application where our
medical clinics, spread out around the city, can share our call center's call
information instantaneously. Microsoft Access has worked beautifully until
now.

Please help.
Kristine
 
T

Todos Menos [MSFT]

I would reccomend not using MDB for anything. It isn't stable enough
in Windows, Citrix or Novell for any real world use.

Access Data Projects have been the preferred method of Access
development for close to a decade.

Sorry

-Todos
 
T

Tony Toews [MVP]

Todos Menos is not a Microsoft employee.
Access Data Projects have been the preferred method of Access
development for close to a decade.

Rubbish.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
G

Guest

Tony,

I've read your (I believe) articles about splitting a database into FE & BE.
I am very much a novice with this but using the wizard splitting was easy. I
am still not clear on the dynamic of all this though and it sounds like I
need to use the Auto FE utility but that's confusing me also so I am hoping
you can clarify some of this for me.

First question, after splitting I know I would put the BE on the server
which all I would know to do is to use H:\\somcifs3\data3\derm which I
usually use for our shared files so hopefully that's okay. Where should the
FE files go? I read to put them on each user computer then in your articles
it says something about putting those also on the server in a folder. Which
would I do?

Second question, where do I find the Auto FE utility? Is this a programming
thing which I would be clueless about or how can I use it? It seems critical
to use Auto FE since my issue is in the fact that we've switched to Citrix.
Could you explain how to use the Auto FE in layman terms? My programming
experience doesn't extend beyond minor tweeking.

I am so very appreciative of your help,
Kristine
 
T

Tony Toews [MVP]

smilee8_28 said:
I've read your (I believe) articles about splitting a database into FE & BE.

Yes, I do have some pages on that topic.
I am very much a novice with this but using the wizard splitting was easy. I
am still not clear on the dynamic of all this though and it sounds like I
need to use the Auto FE utility but that's confusing me also so I am hoping
you can clarify some of this for me.

You don't need to use it. There are other options but it certainly makes life much
more convenient once configured.
First question, after splitting I know I would put the BE on the server
which all I would know to do is to use H:\\somcifs3\data3\derm which I
usually use for our shared files so hopefully that's okay. Where should the
FE files go? I read to put them on each user computer then in your articles
it says something about putting those also on the server in a folder. Which
would I do?

Given a choice you would put them on a local system. That's better for performance
reasons. But you could put them on the server if your IT department won't allow you
any access to the local hard drive.
Second question, where do I find the Auto FE utility?

See the free Auto FE Updater utility at http://www.granite.ab.ca/access/autofe.htm at
my website to keep the FE on each PC up to date.
Is this a programming
thing which I would be clueless about or how can I use it?

Any one can use it. All you need to do is configure it using the INI file.
It seems critical
to use Auto FE since my issue is in the fact that we've switched to Citrix.
Could you explain how to use the Auto FE in layman terms? My programming
experience doesn't extend beyond minor tweeking.

Yikes. Layman terms? That's my biggest problem. I'd suggest starting at the above
URL and seeing how things gof from there.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
T

Tony Toews [MVP]

smilee8_28 said:
See below but also.....do I need to worry about something called 'OpLocks'?

No, they've been fixed for yours in the server and client Windows
operating systems.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
T

Todos Menos [MSFT]

Tony;

it's not rubbish

and I've never claimed to be a Microsoft employee

I previously worked at Microsoft.. for years and years and years

right now I am proclaiming 'anything but microsoft'

and for the record; ADP _IS_ the preferred method of Access
development; and it has been this way for 10 years
I'm sorry that you smoke pole with old dudes in wheelchairs that don't
have the capacity to learn a real database

LINKED TABLE MANAGER?
ROFL

copying queries?
ROFL

lose the training wheels kid!
 
T

Todos Menos [MSFT]

and for the record; you need to learn the difference between a
servername and a mapped network drive

this:

H:\\somcifs3

is not good syntax

if you used ADP you wouldn't have to deal with _ANY_ of this crap
I mean... for reals; lady-- don't listen to this MDB _CRAP_

MDB is a disease anyone that uses it should be fired and then spit
upon


Tony,

I've read your (I believe) articles about splitting a database into FE & BE.
I am very much a novice with this but using the wizard splitting was easy. I
am still not clear on the dynamic of all this though and it sounds like I
need to use the Auto FE utility but that's confusing me also so I am hoping
you can clarify some of this for me.

First question, after splitting I know I would put the BE on the server
which all I would know to do is to use H:\\somcifs3\data3\derm which I
usually use for our shared files so hopefully that's okay. Where should the
FE files go? I read to put them on each user computer then in your articles
it says something about putting those also on the server in a folder. Which
would I do?

Second question, where do I find the Auto FE utility? Is this a programming
thing which I would be clueless about or how can I use it? It seems critical
to use Auto FE since my issue is in the fact that we've switched to Citrix.
Could you explain how to use the Auto FE in layman terms? My programming
experience doesn't extend beyond minor tweeking.

I am so very appreciative of your help,
Kristine



Tony Toews said:
"Todos Menos [MSFT]" <[email protected]> wrote:
Todos Menos is not a Microsoft employee.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm- Hide quoted text -

- Show quoted text -
 
T

Tony Toews [MVP]

Todos Menos said:
and I've never claimed to be a Microsoft employee

Aaron

You are posing as a Microsoft employee every time you put [MSFT] in
your user information in your postings.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
D

David W. Fenton

and for the record; ADP _IS_ the preferred method of Access
development; and it has been this way for 10 years

ADPs did not even exist until Access 2000, and that was released in
June of 1999.

ADPs are currently deprecated by Microsoft and may cease to exist one
or two Access versions down the road. In fact, the current official
word on ADPs, and why they are deprecated, is found here (all on one
line):

http://technet2.microsoft.com/Office/en-us/library/1dce641e-ba1c-
446a-8ff2-221769a58ba51033.mspx?mfr=true

Access Data Projects (ADPs)

An Access Data Project is an OLE document file, like the .xls
or.doc file formats. It contains forms, reports, macros, VBA
modules, and a connection string. All tables and queries are
stored in SQL Server. The ADP architecture was designed to create
client-server applications. Because of this, there is a limit to
the number of records that Access returns in any recordset. This
limit is configurable, but you typically must build enough
filtering into your application so that you do not reach the
limit.

Access uses OLEDB to communicate with SQL Server. To provide the
Jet-like cursor behavior desired for desktop applications, Access
implements the Client Data Manager (CDM) as an additional layer
between Access and OLEDB.

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions. However, there are some scenarios where a report
might be generated significantly faster in an ADP file. To add
these performance improvements and retain the flexibility of SQL
Server, you can build the majority of the application in an MDB or
ACCDB file and have the file load reports from a referenced ADP
file.

One advantage that ADP files have over files in MDB or ACCDB
format is the ability to make design changes to SQL Server
objects. ADP files include graphical designers for tables, views,
stored procedures, functions, and database diagrams.

Particularly note the first sentence of the third paragraph:
 
T

Todos Menos [MSFT]

I AM NOT

I've never seen that 'RULE' anywhere

-Todos [MVP]



Todos Menos said:
and I've never claimed to be a Microsoft employee

Aaron

You are posing as a Microsoft employee every time you put [MSFT] in
your user information in your postings.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
 
T

Todos Menos [MSFT]

Is MVP even a trademark?



Todos Menos said:
and I've never claimed to be a Microsoft employee

Aaron

You are posing as a Microsoft employee every time you put [MSFT] in
your user information in your postings.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
 
T

Todos Menos [MSFT]

Tony;

you are posing as a credible source whenever you put the phrase 'MVP'
in your name

TECHNICALLY; you're an 'Access Baby' and nobody in the world should
listen to you

-Todos

Todos Menos said:
and I've never claimed to be a Microsoft employee

Aaron

You are posing as a Microsoft employee every time you put [MSFT] in
your user information in your postings.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
 
T

Todos Menos [MSFT]

MDBs are currently deprecated by Microsoft and may cease to exist one
or two Access versions down the road. In fact, the current official
word on MDBs, and why they are deprecated, is found here (all on one
line):

Access uses OLEDB to communicate with ACCESS.

this is the most laughable thing I've ever heard in my life:
Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions.

a) ADP has LESS LAYERS
b) SQL Server has 'index tuning wizard' and 'database tuning advisor'
c) SQL Server has _REAL_ db development tools; MDB has _NOTHING_



Because of this, there is an _OPTIONAL_ limit to
the number of records that Access returns in any recordset

I think that this is one of the best features

and I'd take ADP over MDB any day of the week.
I mean MDB scans the whole table across the network.

SQL Server _SEEKS AN INDEX_ and goes to the correct record immediately
 
G

Guest

Okay, so I still want to try getting this split into FE & BE, which still may
not solve my problems because I believe someone may just have a bad computer
(bad NIC or somekind of compatability issue) but my IT people can't help me
with that apparently so I need to exhaust all other possibilities.

Again I am an idiot about this stuff but you have been very helpful and I so
appreciate it. Could you help me figure out what my INI file needs to look
like so I can us the Auto FE utility?

In your Is drive letter INI example is MainApp where an FE version would sit
on my and/or another user's computer?
As far as the server I guess all I know is my MS Access file has always been
on the mapped network drive I use below which is where everyone who will use
this can access it and is that where the BE version needs to be or will it
work there if that is my only option? Or is the directory something different?

What else do I need to change in this INI file?

[Settings]
MainApp=C:\for Log Installs\RX Refills & Nurse Call Log.mde
Server=H:\Logs\RX Refills & Nurse Call Log.mde
CommandLine=/runtime
StartMethod=AutoSelect

Lockout=Yes
LockoutMsg=Sorry, not allowed into the system right now.
SupportMsg=Please contact your computer department for support.

ShortCutName=Shortcut on Desktop
CreateShortCutOnDesktop=Yes
CreateShortCutOnCommonDesktop=No
;ServerShortCutName=Server Shortcut Name
;ShortCutIconFileIndex=27
;ShortCutIconFile=Q:\1 vb\StartMDB\Shell\shell32.dll
;ShortCutCMDFileName=Testing
;ShortCutBATFileName=Testing
;QuickLaunchShortCutName=Testing QL

;Shell=C:\Program Files\Microsoft Office 97\Office\MSACCESS.EXE
;LauncherEXEPath=Q:\1_vb\StartMDB

[Keys]
;Root1=HKEY_LOCAL_MACHINE
;Path1=SOFTWARE\Microsoft\Office\8.0\Access\RefLibPath
;String1=tt_utils.mde
;Value1=$AppPath\tt_utils.mde
 
T

Todos Menos [MSFT]

then why does it take so long?

MDb is a crap architecture

linked tables are laughable

the maintenance is a nightmare

have you ever worked with 4m records in Access?

STFU then kid
 
D

David W. Fenton

MDBs are currently deprecated by Microsoft and may cease to exist
one or two Access versions down the road.

MDBs may cease to exist, but they will be replaced by ACCDBs,
instead, which is just an extended version of the MDB utilizing the
forked Jet 4 database engine.
In fact, the current official
word on MDBs, and why they are deprecated, is found here (all on
one line):

Access uses OLEDB to communicate with ACCESS.

No, that's not true:

http://technet2.microsoft.com/Office/en-us/library/1dce641e-ba1c-446a
-8ff2-221769a58ba51033.mspx?mfr=true

Access Data Projects (ADPs)

An Access Data Project is an OLE document file, like the .xls
or.doc file formats. It contains forms, reports, macros, VBA
modules, and a connection string. All tables and queries are
stored in SQL Server. The ADP architecture was designed to create
client-server applications. Because of this, there is a limit to
the number of records that Access returns in any recordset. This
limit is configurable, but you typically must build enough
filtering into your application so that you do not reach the
limit.

Access uses OLEDB to communicate with SQL Server. To provide the
Jet-like cursor behavior desired for desktop applications, Access
implements the Client Data Manager (CDM) as an additional layer
between Access and OLEDB.

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions. However, there are some scenarios where a report
might be generated significantly faster in an ADP file. To add
these performance improvements and retain the flexibility of SQL
Server, you can build the majority of the application in an MDB or
ACCDB file and have the file load reports from a referenced ADP
file.

One advantage that ADP files have over files in MDB or ACCDB
format is the ability to make design changes to SQL Server
objects. ADP files include graphical designers for tables, views,
stored procedures, functions, and database diagrams.

Particularly note the first sentence of the third paragraph:

Because of the layers required to get from Access to SQL Server in
the ADP architecture, it is often easier to optimize MDB/ACCDB
file solutions.
this is the most laughable thing I've ever heard in my life:

a) ADP has LESS LAYERS

No, it doesn't. The quotation, which is from MS's current Office
2007 documenation website, clearly states that there are exactly the
same number of layers involved.
b) SQL Server has 'index tuning wizard' and 'database tuning
advisor'

Who cares? This has zilch to do with the issue, because we're
talking about MDB vs. ADP for a SQL Server back end, so that fact
that SQL Server has this means nothing, as it's present in both
cases.
c) SQL Server has _REAL_ db development tools; MDB has _NOTHING_

What are you *talking* about? An ADP is only an option if you're
using SQL Server as your back end. You seem to be completely
confused about the nature of Access as both front end and back end.
Because of this, there is an _OPTIONAL_ limit to
the number of records that Access returns in any recordset

I think that this is one of the best features

and I'd take ADP over MDB any day of the week.
I mean MDB scans the whole table across the network.

Here you betray the massive depths of your ignorance of the subject
on which you claim to be an expert.
SQL Server _SEEKS AN INDEX_ and goes to the correct record
immediately

And when you're connected to SQL Server from an MDB, SQL Server does
EXACTLY THE SAME THING.
 
T

Todos Menos [MSFT]

a) Access _DOES_ use OLEDB to talk in between MDB. it's been that way
since Access 2000; no ODBC
b) MDB is dead. ADP is the future.

Don't listen to this friggin retard
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top