use Form in BE as subForm

  • Thread starter Thread starter Andi Mayer
  • Start date Start date
A

Andi Mayer

Hi All

does anybody know how to use a Form from the BackEnd in the FrontEnd
as subform without copying it into the FE?

if I use in a Form in the FE:

set frm as new Form_fromBE
Me.subFormControl.SourceObject=frm.Name

Access doesn't find the object

Also if I write a function in the BE to set frm to the form it
doesn't work as a subForm, as a form it is usable.

If you expect an answer to a personal mail, add the word "manfred" to the first 10 lines in the message
MW
 
What you ask is not possible. All objects must reside in the open database
mdb. Only data tables can be linked to another file. What's the problem
with just importing a copy of the form you want into the front-end mdb?
-Ed
 
What you ask is not possible. All objects must reside in the open database
mdb. Only data tables can be linked to another file. What's the problem
with just importing a copy of the form you want into the front-end mdb?
-Ed
Click to expand...

It takes extra code to delete and import it at every start and I have
to manage which forms I need for the different FE's

If you expect an answer to a personal mail, add the word "manfred" to the first 10 lines in the message
MW
 
Not sure what you really need then, but I have many apps that use a variety
of front-ends (to limit feature sets to different users). I keep a "master"
front-end with all the forms/reports/etc. and use the object description
text (though you could add symbols the to object name itself) to keep track
of those objects that need revising ( by import/delete) in the various
front-ends.
-Ed
 
A more basic question then - why does the Form need to keep changing!?
Click to expand...

because this is an endless project (IBM-U2 Application to Access)

the BE is a bunch of classes to import Data from an MultValue Database
and with every FE there are a few changes which I want to use in the
other FE's, like a new Textbox.....

The main reason is that I want to concentrate most of the object in
the BE for maintenance.

If you expect an answer to a personal mail, add the word "manfred" to the first 10 lines in the message
MW
 
Andi Mayer said:
because this is an endless project (IBM-U2 Application to Access)

the BE is a bunch of classes to import Data from an MultValue Database
and with every FE there are a few changes which I want to use in the
other FE's, like a new Textbox.....
Click to expand...

The fact of the data being from a MV database should not change the fact
that even data from a MV database can be viewed logically as a normalized
dataset. In fact, most MV vendors allow the MV data to be worked on via sql,
and thus a single record from MV land becomes two tables in sql that you
have to join back together.

I can certainly understand that you might have a form that needs the ability
to display *different* sub-form (you can actually just change the source
object setting of the sub-form control...and poof!..it displays a different
sub-form).

however, the idea of changing what sub-form displays is easy..but the
concept of runtime adding, or deleting text boxes should not be needed at
all here. And mv-data should become a sub-form..and it should "rare" that
additional fields are being added (something is not right here! Perhaps the
MV system is also under development..and new fields are being added...but if
the MV system is static and not under current development, then your table
designs and forms should not be needed to be changed).

If new changes are needed to be distributed to the front ends, then you need
to distribute a new FE (mde) to each user. I would consider using Tony's
auto FE updater to make this painless...found here:
http://www.granite.ab.ca/access/autofe.htm.

And, you might enjoy and find this article of mine on the steps and pit
falls of converting a MV application to ms-access here:

http://www.attcanada.net/~kallal.msn/Articles/fog0000000003.html
 
The fact of the data being from a MV database should not change the fact
that even data from a MV database can be viewed logically as a normalized
dataset. In fact, most MV vendors allow the MV data to be worked on via sql,
and thus a single record from MV land becomes two tables in sql that you
have to join back together.
Click to expand...

I started with the SQL Idee, but I had to give it up, due to the fact
that the MV-Table design is horrible and the programming too.
for example:
Artikel-Table has 426 Fields, the dictionary ~1000 Field-definitions
where ~200 are with wrong information and 20 Sub-MV fields. No
information about dependend fields.

The application was a former PICK-App and was (and is) converted to
SB+
however, the idea of changing what sub-form displays is easy..but the
concept of runtime adding, or deleting text boxes should not be needed at
all here. And mv-data should become a sub-form..and it should "rare" that
additional fields are being added (something is not right here! Perhaps the
MV system is also under development..and new fields are being added...but if
the MV system is static and not under current development, then your table
designs and forms should not be needed to be changed).
Click to expand...

Example:
one of the FE is for Price-calculations for Internal-Orders. Here I
don't need the selling price, another (writen afterwards) needs the
price, therefore I change the form to include this field and use the
same Form also in the first FE. All the importing code (uniObjects)
sits in the BE and therefore every FE gets the same Data, because I
use a "Dictionary-emulation"

If new changes are needed to be distributed to the front ends, then you need
to distribute a new FE (mde) to each user. I would consider using Tony's
auto FE updater to make this painless...found here:
http://www.granite.ab.ca/access/autofe.htm.
Click to expand...

I decided now to move this to the BE also, I will use a table where
the FE looks for Imports
And, you might enjoy and find this article of mine on the steps and pit
falls of converting a MV application to ms-access here:

http://www.attcanada.net/~kallal.msn/Articles/fog0000000003.html
Click to expand...

I knew this artikel, I have read it a year ago when I started the
project with SQL, but the hassle to change the Dictionary (@SELECT)
was to much. The main reason to change to UniObject was then a
time-factor and the poor and strange implementation of SQL in
Universe.

If you expect an answer to a personal mail, add the word "manfred" to the first 10 lines in the message
MW
 
I started with the SQL Idee, but I had to give it up, due to the fact
that the MV-Table design is horrible and the programming too.
for example:
Artikel-Table has 426 Fields, the dictionary ~1000 Field-definitions
Click to expand...

The above number of fields, and the large number of field defs is not
un-usual in those pick systems.
where ~200 are with wrong information and 20 Sub-MV fields.
Click to expand...

The above certainly makes things quite difficult. I often see systems where
there is a LOT of additional fields (dict defs) that are not needed, or not
even in use, or as you say...just wrong!. And, worse is when controlling and
dependents fields are not set.

Dissipate this large dictionary problem, I would still actually map out the
tables defs. Even if controlling and dependent attributes are not set
correctly, you do need to at least create a table definition or "map" of the
current data structures. The fact that you know 426 fields exist out of 1000
dict defs does suggest you are/have been doing this already. This does not
mean you will use sql here, but you do need a "document" that shows you the
table data.

There is also the issue of where the data is to reside. If you are using
ms-access to edit and manipulate the data, but then storing it back on the
Universe machine..I not sure ms-access + Uni-Objects is the best approach
here. If you are just using ms-access as a reporting tool, then again, you
likely would be better off getting sql/odbc to work then using Uni-Objects.
Using Uni-Objects generally means that you will be using un-bound forms, or
writing lots of code to just grab data from the pick side and placing the
data into a table.
one of the FE is for Price-calculations for Internal-Orders. Here I
Click to expand...
don't need the selling price, another (written afterwards) needs the
price, therefore I change the form to include this field and use the
same Form also in the first FE.

For the above...you simply set the visible property of the Selling price
text box..right? (ms-access, or just about any development environment will
not tolerate design table changes at runtime. So, for the above...I would
just set the visible property of the Selling Price text box. Even the SB+
system for pick does not use designs that change at runtime. This applies to
both systems.

Anyway...those mv systems can be a real handful. However, just take your
time...and eventually everything on those systems will make sense! MV
systems are very capable, but just very different to most people who have
not seen the mv model.


Good luck!
 
There is also the issue of where the data is to reside. If you are using
ms-access to edit and manipulate the data, but then storing it back on the
Universe machine..I not sure ms-access + Uni-Objects is the best approach
here. If you are just using ms-access as a reporting tool, then again, you
likely would be better off getting sql/odbc to work then using Uni-Objects.
Using Uni-Objects generally means that you will be using un-bound forms, or
writing lots of code to just grab data from the pick side and placing the
data into a table.
Click to expand...

I have written a class which wraps around the uniObjects and it need a
"one_liner" to get the data (but one to two days to analyse a
Pick_file)

How you are managing the Dictionaries regarding the SQL, speciall if
you have a numeric field and somebody has "managed" to include a
letter into it?
For the above...you simply set the visible property of the Selling price
text box..right? (ms-access, or just about any development environment will
not tolerate design table changes at runtime. So, for the above...I would
just set the visible property of the Selling Price text box. Even the SB+
system for pick does not use designs that change at runtime. This applies to
both systems.
Click to expand...

in my case it works, because with every import I produce new tables,
therefore he can work with the textbox.

Anyway...those mv systems can be a real handful. However, just take your
time...and eventually everything on those systems will make sense! MV
systems are very capable, but just very different to most people who have
not seen the mv model.
Click to expand...

I love this system, but the original programmer doesn't know what he
(was and) is doing, for example I found three different
price-calculations in a single form (on open he recalcs, if he change
a MV-item he recals the line, and on closing he recalcs again). this
shows that he knows that he is making calculation errors and he is
trying to hide it. The result is: what it's stored must not be the
right result.
I can't analyse the 4500 procedures which are on the system, not even
the programmer knows it. He cancelled the service contract, because we
showed him to much errors in his programm.
Good luck!
Click to expand...
Thats exactly what i need, thanks

If you expect an answer to a personal mail, add the word "manfred" to the first 10 lines in the message
MW
 
How you are managing the Dictionaries regarding the SQL, speciall if
you have a numeric field and somebody has "managed" to include a
letter into it?
Click to expand...

Gee..I have no idea what to do with the above issue. I would assume that you
have the column retuned as a text field..and not a numeric...
 
Back
Top