How much to convert to SQL server

[Jan]

Hi:

I have an Access database that's been running (in one form or another)
for a couple of different clients for a few years. Now a new client has
requested that it be implemented with a SQL server back-end. I'm doing
my best to learn about SQL server, and I plan to leave the front-end
more or less as-is, just linking to the SQL server back end, but here's
a basic question:

The db has a front-end linked to two back-ends. One of the back-ends has
completely static data, and so in an all-Access installation it sits on
the C drive along with the front end. Only the 2nd backend sits
on the server.

Now, should I convert both back-ends to SQL server, or just the one on
the server? Reasons, pros, cons?

TIA.

Jan

[Larry Linson]

Re: How much to convert to SQL server

Your new client is the one who wants the conversion and, presumably, is
paying you to convert the database. You should be asking the client what
_they_ want, but be ready with logical arguments if they want something
"flakey".

The following applies only to Access MDB, using ODBC drivers, to link to an
SQL server database:

Relatively unchanging lookup tables are often kept local to an Access
application -- States in the US is a prime example, company structure
(divisions, departments) is another. I'd personally see no need to migrate
static data to the back-end and have to access it across a
possibly-slower-than-I'd-like network.

Still, the client may have their own reasons (or even prejudices) and ideas
about what can reasonably be moved to the backend.

Larry Linson
Microsoft Access MVP



"Jan" <jan@stempelcon sulting.com> wrote in message
news:11v77m878q sla75@corp.supe rnews.com...[color=blue]
> Hi:
>
> I have an Access database that's been running (in one form or another)
> for a couple of different clients for a few years. Now a new client has
> requested that it be implemented with a SQL server back-end. I'm doing
> my best to learn about SQL server, and I plan to leave the front-end
> more or less as-is, just linking to the SQL server back end, but here's
> a basic question:
>
> The db has a front-end linked to two back-ends. One of the back-ends has
> completely static data, and so in an all-Access installation it sits on
> the C drive along with the front end. Only the 2nd backend sits
> on the server.
>
> Now, should I convert both back-ends to SQL server, or just the one on
> the server? Reasons, pros, cons?
>
> TIA.
>
> Jan[/color]

[Jan]

Re: How much to convert to SQL server

Hi, Larry:

Thanks for the quick reply.

Unfortunately, the client isn't directly mine; I'm more or less a
subcontractor. I'm not sure they know exactly why they want SQL Server,
except that they think it's the "better" way. And I'm not in a position
to argue. They do have some issues with lots of users possibly spread
out over several offices.

Anyway, I just wanted to be sure there wouldn't be some advantage to
having all the linked tables be converted to SQL Server. And yes, I'm
planning to use the ODBC link to the SQL Server backend. My preference
is certainly to keep as much of the data local, and in Access, as
possible, if only because it's what I know best.

Anyone have any other views?

Jan

Larry Linson wrote:[color=blue]
> Your new client is the one who wants the conversion and, presumably,
> is paying you to convert the database. You should be asking the
> client what _they_ want, but be ready with logical arguments if they
> want something "flakey".
>
> The following applies only to Access MDB, using ODBC drivers, to link
> to an SQL server database:
>
> Relatively unchanging lookup tables are often kept local to an Access
> application -- States in the US is a prime example, company
> structure (divisions, departments) is another. I'd personally see no
> need to migrate static data to the back-end and have to access it
> across a possibly-slower-than-I'd-like network.
>
> Still, the client may have their own reasons (or even prejudices) and
> ideas about what can reasonably be moved to the backend.
>
> Larry Linson Microsoft Access MVP
>
>
>
> "Jan" <jan@stempelcon sulting.com> wrote in message
> news:11v77m878q sla75@corp.supe rnews.com...
>[color=green]
>> Hi:
>>
>> I have an Access database that's been running (in one form or
>> another) for a couple of different clients for a few years. Now a
>> new client has requested that it be implemented with a SQL server
>> back-end. I'm doing my best to learn about SQL server, and I plan
>> to leave the front-end more or less as-is, just linking to the SQL
>> server back end, but here's a basic question:
>>
>> The db has a front-end linked to two back-ends. One of the
>> back-ends has completely static data, and so in an all-Access
>> installation it sits on the C drive along with the front end. Only
>> the 2nd backend sits on the server.
>>
>> Now, should I convert both back-ends to SQL server, or just the one
>> on the server? Reasons, pros, cons?
>>
>> TIA.
>>
>> Jan[/color]
>
>
>[/color]

[Rick Brandt]

Re: How much to convert to SQL server

Jan wrote:[color=blue]
> Hi, Larry:
>
> Thanks for the quick reply.
>
> Unfortunately, the client isn't directly mine; I'm more or less a
> subcontractor. I'm not sure they know exactly why they want SQL
> Server, except that they think it's the "better" way. And I'm not in
> a position to argue. They do have some issues with lots of users
> possibly spread out over several offices.
>
> Anyway, I just wanted to be sure there wouldn't be some advantage to
> having all the linked tables be converted to SQL Server. And yes, I'm
> planning to use the ODBC link to the SQL Server backend. My
> preference is certainly to keep as much of the data local, and in
> Access, as possible, if only because it's what I know best.
>
> Anyone have any other views?[/color]

Well even if you want to keep a few tables local (I see no reason to) you would
often want another copy of the same table on the server if it is ever used in a
query. You don't want to create queries in Access that use both a local table
and a link to a server table. That would definitely be an inefficient query to
run unless the local table was very small).

In my Access FE/SQL Server BE apps ALL the tables are on the server and
performance is just fine on a standard 100 mb LAN.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[david epsom dot com dot au]

Re: How much to convert to SQL server

If you are using transactions, you probably want to re-write
any transactions that include the static tables. If you use
local jet tables, the transactions are more likely to block
internally, and if you use SQL Server tables, the transactions
are likely to block other users.

(david)



"Jan" <jan@stempelcon sulting.com> wrote in message
news:11v7c5l7h5 ig7dc@corp.supe rnews.com...[color=blue]
> Hi, Larry:
>
> Thanks for the quick reply.
>
> Unfortunately, the client isn't directly mine; I'm more or less a
> subcontractor. I'm not sure they know exactly why they want SQL Server,
> except that they think it's the "better" way. And I'm not in a position
> to argue. They do have some issues with lots of users possibly spread
> out over several offices.
>
> Anyway, I just wanted to be sure there wouldn't be some advantage to
> having all the linked tables be converted to SQL Server. And yes, I'm
> planning to use the ODBC link to the SQL Server backend. My preference
> is certainly to keep as much of the data local, and in Access, as
> possible, if only because it's what I know best.
>
> Anyone have any other views?
>
> Jan
>
> Larry Linson wrote:[color=green]
>> Your new client is the one who wants the conversion and, presumably,
>> is paying you to convert the database. You should be asking the client
>> what _they_ want, but be ready with logical arguments if they
>> want something "flakey".
>>
>> The following applies only to Access MDB, using ODBC drivers, to link
>> to an SQL server database:
>>
>> Relatively unchanging lookup tables are often kept local to an Access
>> application -- States in the US is a prime example, company structure
>> (divisions, departments) is another. I'd personally see no
>> need to migrate static data to the back-end and have to access it across
>> a possibly-slower-than-I'd-like network.
>>
>> Still, the client may have their own reasons (or even prejudices) and
>> ideas about what can reasonably be moved to the backend.
>>
>> Larry Linson Microsoft Access MVP
>>
>>
>>
>> "Jan" <jan@stempelcon sulting.com> wrote in message
>> news:11v77m878q sla75@corp.supe rnews.com...
>>[color=darkred]
>>> Hi:
>>>
>>> I have an Access database that's been running (in one form or another)
>>> for a couple of different clients for a few years. Now a
>>> new client has requested that it be implemented with a SQL server
>>> back-end. I'm doing my best to learn about SQL server, and I plan
>>> to leave the front-end more or less as-is, just linking to the SQL
>>> server back end, but here's a basic question:
>>>
>>> The db has a front-end linked to two back-ends. One of the back-ends
>>> has completely static data, and so in an all-Access installation it sits
>>> on the C drive along with the front end. Only
>>> the 2nd backend sits on the server.
>>>
>>> Now, should I convert both back-ends to SQL server, or just the one
>>> on the server? Reasons, pros, cons?
>>>
>>> TIA.
>>>
>>> Jan[/color]
>>
>>[/color][/color]

[Jan]

Re: How much to convert to SQL server

No transactions in this one.

david epsom dot com dot au wrote:[color=blue]
> If you are using transactions, you probably want to re-write
> any transactions that include the static tables. If you use
> local jet tables, the transactions are more likely to block
> internally, and if you use SQL Server tables, the transactions
> are likely to block other users.
>
> (david)
>
>
>
> "Jan" <jan@stempelcon sulting.com> wrote in message
> news:11v7c5l7h5 ig7dc@corp.supe rnews.com...
>[color=green]
>>Hi, Larry:
>>
>>Thanks for the quick reply.
>>
>>Unfortunately , the client isn't directly mine; I'm more or less a
>>subcontractor . I'm not sure they know exactly why they want SQL Server,
>>except that they think it's the "better" way. And I'm not in a position
>>to argue. They do have some issues with lots of users possibly spread
>>out over several offices.
>>
>>Anyway, I just wanted to be sure there wouldn't be some advantage to
>>having all the linked tables be converted to SQL Server. And yes, I'm
>>planning to use the ODBC link to the SQL Server backend. My preference
>>is certainly to keep as much of the data local, and in Access, as
>>possible, if only because it's what I know best.
>>
>>Anyone have any other views?
>>
>>Jan
>>
>>Larry Linson wrote:
>>[color=darkred]
>>>Your new client is the one who wants the conversion and, presumably,
>>> is paying you to convert the database. You should be asking the client
>>>what _they_ want, but be ready with logical arguments if they
>>> want something "flakey".
>>>
>>>The following applies only to Access MDB, using ODBC drivers, to link
>>> to an SQL server database:
>>>
>>>Relatively unchanging lookup tables are often kept local to an Access
>>> application -- States in the US is a prime example, company structure
>>>(divisions , departments) is another. I'd personally see no
>>> need to migrate static data to the back-end and have to access it across
>>>a possibly-slower-than-I'd-like network.
>>>
>>>Still, the client may have their own reasons (or even prejudices) and
>>> ideas about what can reasonably be moved to the backend.
>>>
>>>Larry Linson Microsoft Access MVP
>>>
>>>
>>>
>>>"Jan" <jan@stempelcon sulting.com> wrote in message
>>>news:11v77m8 78qsla75@corp.s upernews.com...
>>>
>>>
>>>>Hi:
>>>>
>>>>I have an Access database that's been running (in one form or another)
>>>>for a couple of different clients for a few years. Now a
>>>> new client has requested that it be implemented with a SQL server
>>>> back-end. I'm doing my best to learn about SQL server, and I plan
>>>> to leave the front-end more or less as-is, just linking to the SQL
>>>> server back end, but here's a basic question:
>>>>
>>>>The db has a front-end linked to two back-ends. One of the back-ends
>>>>has completely static data, and so in an all-Access installation it sits
>>>>on the C drive along with the front end. Only
>>>> the 2nd backend sits on the server.
>>>>
>>>>Now, should I convert both back-ends to SQL server, or just the one
>>>> on the server? Reasons, pros, cons?
>>>>
>>>>TIA.
>>>>
>>>>Jan
>>>
>>>[/color][/color]
>[/color]

[Jan]

Re: How much to convert to SQL server

Hi, Rick:

This is a key one, I guess, because there are certainly queries that run
with some tables from each of the different sets. Most of the tables
are in the local set, but there are a crucial few that need to be on
the server. In the past, when it has been an entirely Access database,
I moved all the static tables to the local drive because it vastly
improved performance.

So do you think that with a SQL server backend I wouldn't run into the
slowness issues that I had with an all-Access db?

I have to say I'm really anxious about this whole conversion process.
The client is out of town and I have to make it work in a very short
time period when I'm out there. I can test it here on my machine, with
the "developers " version of SQL Server, but I worry that it isn't a good
proxy for the
"real thing."

Jan

Rick Brandt wrote:[color=blue]
> Jan wrote:
>[color=green]
>> Hi, Larry:
>>
>> Thanks for the quick reply.
>>
>> Unfortunately, the client isn't directly mine; I'm more or less a
>> subcontractor. I'm not sure they know exactly why they want SQL
>> Server, except that they think it's the "better" way. And I'm not
>> in a position to argue. They do have some issues with lots of
>> users possibly spread out over several offices.
>>
>> Anyway, I just wanted to be sure there wouldn't be some advantage
>> to having all the linked tables be converted to SQL Server. And
>> yes, I'm planning to use the ODBC link to the SQL Server backend.
>> My preference is certainly to keep as much of the data local, and
>> in Access, as possible, if only because it's what I know best.
>>
>> Anyone have any other views?[/color]
>
>
> Well even if you want to keep a few tables local (I see no reason to)
> you would often want another copy of the same table on the server if
> it is ever used in a query. You don't want to create queries in
> Access that use both a local table and a link to a server table. That
> would definitely be an inefficient query to run unless the local
> table was very small).
>
> In my Access FE/SQL Server BE apps ALL the tables are on the server
> and performance is just fine on a standard 100 mb LAN.
>[/color]

[Rick Brandt]

Re: How much to convert to SQL server


"Jan" <jan@stempelcon sulting.com> wrote in message
news:11v7mcfk0l p1a14@corp.supe rnews.com...[color=blue]
> Hi, Rick:
>
> This is a key one, I guess, because there are certainly queries that run
> with some tables from each of the different sets. Most of the tables
> are in the local set, but there are a crucial few that need to be on
> the server. In the past, when it has been an entirely Access database,
> I moved all the static tables to the local drive because it vastly
> improved performance.
>
> So do you think that with a SQL server backend I wouldn't run into the
> slowness issues that I had with an all-Access db?[/color]

If a query is slow because it is poorly designed then putting the tables on a
server won't magically fix that. If a query is slow because it is working
against very large tables then putting those tables on a server won't magically
cure that either.

There are many advantages to moving to a server-based data engine. Raw query
performance is not one of them. People often see performance gains when setting
up a new box for SQL Server because they will usually build that server with
high-spec'd hardware. Several years ago just about any server would be WAY more
capable than a desktop PC. That is still true, but not to the degree that it
once was because desktop PCs are simply very capable these days.

Client/Server performance is largely driven by minimizing traffic over the LAN
and good design. Those same strategies would likely result in an MDB Based
database that also performed well.


--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Larry Linson]

Re: How much to convert to SQL server


"Rick Brandt" <rickbrandt2@ho tmail.com> wrote
[color=blue]
> Well even if you want to keep a few tables
> local (I see no reason to) you would
> often want another copy of the same table
> on the server if it is ever used in a
> query.[/color]

I specifically said, rarely-changing _lookup_ tables, with examples. I've
done this, with a master copy on the server, from which the local tables are
refreshed at startup, if need be. Running over a WAN, it is likely you'll
see some performance improvment if there are quite a few.
[color=blue]
> You don't want to create queries in Access that
> use both a local table and a link to a server table.
> That would definitely be an inefficient query to
> run unless the local table was very small).[/color]

I _strongly_ agree. In fact, even if the local table is very small, the
performance impact can be substantial because the entire table may be
brought from the server to the user's machine for the join. <OUCH!>
[color=blue]
> In my Access FE/SQL Server BE apps ALL
> the tables are on the server and performance is
> just fine on a standard 100 mb LAN.[/color]

Of course. But, move some of your users to the boonies on a WAN that shares
a T-1 line and you are likely to see a discernable difference. That's where
you may need to resort to "performanc e tricks".

If you have appropriate instrumentation , the difference may be "measurable "
on a 100 MBPS LAN, but it's unlikely to be discernable to someone sitting in
front of a screen. We didn't bother with local tables when everyone was on
the high-speed LAN.

Larry Linson
Microsoft Access MVP

[Jan]

Re: How much to convert to SQL server

I don't know why exactly the database runs slow with the tables on the
server; I only know that when I moved them to the local disk, a
particular activity (which involves a lot of data manipulation, writing
to a Word document, and a variety of other tasks) went from taking 5
minutes down to less than one. I always blamed it on the slowness of
the client's network, but frankly didn't spend a lot of time
contemplating the reasons; the solution was very effective and I left it
at that.

Maybe this will help you understand the situation: the users are
entering data on rental units. The database is running a model that
involves manipulating a large amount of stored data on other rental
units (that's the static part; the research is done once and stays the
same for a year), but it has to be compared and calculations made in
order to come to some recommendations on the newly-entered unit.
Thus, most of the data is static, but that new record has to be involved.

Make any sense?

So maybe the question is this:
if I haven't had a performance hit from running queries that involved
both local and server tables in the past, would I have that hit when the
"server" tables are SQL Server and the local tables are Access?

Jan

Rick Brandt wrote:[color=blue]
> "Jan" <jan@stempelcon sulting.com> wrote in message
> news:11v7mcfk0l p1a14@corp.supe rnews.com...
>[color=green]
>> Hi, Rick:
>>
>> This is a key one, I guess, because there are certainly queries
>> that run with some tables from each of the different sets. Most of
>> the tables are in the local set, but there are a crucial few that
>> need to be on the server. In the past, when it has been an
>> entirely Access database, I moved all the static tables to the
>> local drive because it vastly improved performance.
>>
>> So do you think that with a SQL server backend I wouldn't run into
>> the slowness issues that I had with an all-Access db?[/color]
>
>
> If a query is slow because it is poorly designed then putting the
> tables on a server won't magically fix that. If a query is slow
> because it is working against very large tables then putting those
> tables on a server won't magically cure that either.
>
> There are many advantages to moving to a server-based data engine.
> Raw query performance is not one of them. People often see
> performance gains when setting up a new box for SQL Server because
> they will usually build that server with high-spec'd hardware.
> Several years ago just about any server would be WAY more capable
> than a desktop PC. That is still true, but not to the degree that it
> once was because desktop PCs are simply very capable these days.
>
> Client/Server performance is largely driven by minimizing traffic
> over the LAN and good design. Those same strategies would likely
> result in an MDB Based database that also performed well.
>
>[/color]

[Rick Brandt]

Re: How much to convert to SQL server


"Jan" <jan@stempelcon sulting.com> wrote in message
news:11v7rq75bv k9t85@corp.supe rnews.com...[color=blue]
>I don't know why exactly the database runs slow with the tables on the
> server; I only know that when I moved them to the local disk, a
> particular activity (which involves a lot of data manipulation, writing
> to a Word document, and a variety of other tasks) went from taking 5
> minutes down to less than one. I always blamed it on the slowness of
> the client's network, but frankly didn't spend a lot of time
> contemplating the reasons; the solution was very effective and I left it
> at that.
>
> Maybe this will help you understand the situation: the users are
> entering data on rental units. The database is running a model that
> involves manipulating a large amount of stored data on other rental
> units (that's the static part; the research is done once and stays the
> same for a year), but it has to be compared and calculations made in
> order to come to some recommendations on the newly-entered unit.
> Thus, most of the data is static, but that new record has to be involved.
>
> Make any sense?
>
> So maybe the question is this:
> if I haven't had a performance hit from running queries that involved
> both local and server tables in the past, would I have that hit when the
> "server" tables are SQL Server and the local tables are Access?[/color]

Impossible to predict, but on the surface I can think of no reason for
performance to be worse. I just don't see much reason to believe it would be
any better either.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Jan]

Re: How much to convert to SQL server

Well, it doesn't have to be better, it just has to be comparable.

Slightly different question here: will my testing on the local copy of
SQL server be in any way comparable to how the thing will behave in a
real production environment? I know that when I develop in general,
systems that work fast on my single-user machine can get very poky once
they hit the client's network. Is it the same with the developer's
edition of SQL server vs the full-blown one?

Rick Brandt wrote:[color=blue]
> "Jan" <jan@stempelcon sulting.com> wrote in message
> news:11v7rq75bv k9t85@corp.supe rnews.com...
>[color=green]
>> I don't know why exactly the database runs slow with the tables on
>> the server; I only know that when I moved them to the local disk, a
>> particular activity (which involves a lot of data manipulation,
>> writing to a Word document, and a variety of other tasks) went
>> from taking 5 minutes down to less than one. I always blamed it
>> on the slowness of the client's network, but frankly didn't spend a
>> lot of time contemplating the reasons; the solution was very
>> effective and I left it at that.
>>
>> Maybe this will help you understand the situation: the users are
>> entering data on rental units. The database is running a model
>> that involves manipulating a large amount of stored data on other
>> rental units (that's the static part; the research is done once and
>> stays the same for a year), but it has to be compared and
>> calculations made in order to come to some recommendations on the
>> newly-entered unit. Thus, most of the data is static, but that new
>> record has to be involved.
>>
>> Make any sense?
>>
>> So maybe the question is this: if I haven't had a performance hit
>> from running queries that involved both local and server tables in
>> the past, would I have that hit when the "server" tables are SQL
>> Server and the local tables are Access?[/color]
>
>
> Impossible to predict, but on the surface I can think of no reason
> for performance to be worse. I just don't see much reason to believe
> it would be any better either.
>[/color]

[Lyle Fairfield]

Re: How much to convert to SQL server

If it's been running for a few years undoubtedly it needs a complete
revision. Take the opportunity to trash the whole thing and start over.
I get sick to my stomach whenever I see anything of mine that is more
than two years old.

[robert d via AccessMonster.com]

Re: How much to convert to SQL server

I had a client ask me to substitue the Jet backend with SQL Server. The
logic they used for deciding which tables to put on SQL Server was:

"Our data needs to be on SQL Server".

Therefore, presumably data which was not theirs (like zip code tables, etc)
could remain local. Also, my proprietary tables could remain local as well.
Didn't do the job and have not thoroughly read the other posts in this thread.
Just passing on what their criteria was.


Jan wrote:[color=blue]
>No transactions in this one.
>[color=green]
>> If you are using transactions, you probably want to re-write
>> any transactions that include the static tables. If you use[/color]
>[quoted text clipped - 63 lines][color=green][color=darkred]
>>>>>
>>>>>Jan[/color][/color][/color]

--
Message posted via AccessMonster.c om

http://www.accessmonster.com/Uwe/Forums.aspx/databases-ms-access/200602/1

[salad]

Re: How much to convert to SQL server

Jan wrote:[color=blue]
> I don't know why exactly the database runs slow with the tables on the
> server; I only know that when I moved them to the local disk, a
> particular activity (which involves a lot of data manipulation, writing
> to a Word document, and a variety of other tasks) went from taking 5
> minutes down to less than one.[/color]

That's a phenomenally long time. I call that coffee-break coding...as
in I want to run the process but take a break.

If I'm not getting results back in 5 seconds (absolute tops) or less.
then there is a problem. If course, I'm not dealing with millions of
records, but for a typical desktop app 5 minutes is way, way too long.

Back in the old days I'd immediately suspect a field I am filtering on,
in a where clause, is not indexed. But in Access where I see people
discussing their coffee-break queries they usually are doing sub-selects
in the query. That's nearly a guaranteed yawner of a query.

I suspect that most regulars in this newsgroup could get your query down
to a couple of seconds if they were working on your application.

I always blamed it on the slowness of[color=blue]
> the client's network, but frankly didn't spend a lot of time
> contemplating the reasons; the solution was very effective and I left it
> at that.[/color]

Time is money. That's why there's a FedEx. If I can shave 5 minutes of
processing on something that is done every weekday day by 10 users, in a
year the time saving is about 210 hours. You do that for a few more
processes and you're taking some significant time.[color=blue]
>
> Maybe this will help you understand the situation: the users are
> entering data on rental units. The database is running a model that
> involves manipulating a large amount of stored data on other rental
> units (that's the static part; the research is done once and stays the
> same for a year), but it has to be compared and calculations made in
> order to come to some recommendations on the newly-entered unit.
> Thus, most of the data is static, but that new record has to be involved.
>
> Make any sense?
>
> So maybe the question is this:
> if I haven't had a performance hit from running queries that involved
> both local and server tables in the past, would I have that hit when the
> "server" tables are SQL Server and the local tables are Access?
>[/color]
Well, I can see why the client may want to go to SQL Server, anything
that may help cut down that 5 minute processing time. I simply don't
see SQLServer as the optimum solution. If the time lag was bad before,
why will it be better with SQLServer? Doubtful. Will your client be
happy if, instead of a 5 minute lag time, you cut it down to 4 minutes?
I wouldn't. The more instantaneous you do something, the better.

You do mention a "large amount of data". That means nothing to me or
many developers. Does that mean millions of records? Or does it mean a
few thousand records with a couple hundred fields?

I would really look at your queries. If you use subselects in any of
them, change tactics. Check your indexing and filtering. Do some time
tests.


[color=blue]
> Jan[/color]